## 奖牌榜改名(主人要求)
「团体奖牌榜」→「单位奖牌榜」,界面 / 大屏渲染页 / 导出件(工作表名与
下载文件名 `单位奖牌明细.xlsx`)/ 用户文档 全部统一;`DISPLAY_PAGES` 是
大屏控制页与大屏页的共同来源,改一处两边同时生效。旧名保留为别名,
老链接与老配置(`display.pages`)照常有效。真 Chromium 验证:14 个管理端
路由 + 7 个基础数据分区 0 报错,大屏页标题已是「单位奖牌榜」。
## P2 清单(123 条,103 条标「建议修」)
按 A/B/C/D 分组、以「文件所有权互斥」分 10 个代理并行推进,另有独立复核
代理逐条核对:61 条声称已修 / 55 条证实 / 4 条部分 / 0 条不成立 / 0 垃圾。
主要交付(按风险从高到低):
- 写入侧校验:update 路径补必填与 TrimSpace、模板 rules 重复 rank、
「小项不存在」的四种回答、`defaultProfileId` 外键、decodeJSON 的 8MB
上限与 413(A01–A06、D02、D03 批量上限 500)
- 危险操作:一键恢复加互斥(第二个请求当场 409)、恢复超时不再说
「未执行」、`ConfirmDialog` pending 时锁死 ESC/遮罩/关闭
- 认证:改密与撤会话进同一事务、滑动续期写库失败不再假装成功、
CSRF Cookie 丢失自动补发、密码长度按字符(原按字节)、
反代 403 只在可信代理透传原 Host 时采信 `X-Forwarded-Host`(全等比较)、
过期会话定期清理、登出补审计、登录限流可配
- 数据可见性:导出「已发布未结算」行改为 `名次 — / 积分 — / 状态未结算`、
单位积分明细成绩列与其它导出件逐字一致、空单位也打合计行、
基础数据包命中「已彻底删除的单位」整行跳过并报界面路径、
报名导入换单位给明确提示、勾选报名有冲突不再假报成功
- 导入/导出:赛事包上限 512MB(**它是唯一带字体/图片的包**,字体上限
20MB)而 multipart 内存档位独立钉在 16MB、工作簿表名尾随空格、
导出件路由与文件名契约补全
- 前端:一次写请求只生成一个 requestId(幂等缓存此前从未命中)、
基础数据包补 `X-Request-Id`、示例数据模式禁写扩到撤销发布/存草稿、
访客 401 不再是裸错误、模板 `{{else if}}` 不再静默吞内容
- Console:按设计退出(切赛事/恢复)不再判成崩溃、旧数据目录读不出来
会记日志、渲染层日志按上限截断、`service.js` 补 17 例测试
## 测试
服务端用例 610 → 674(13 包全绿,新增老库跨九条迁移升级、panic 形状、
429 落 interceptions、三态对照、avg_mode 分母、会话失效、请求体上限等)
前端 449 → 531(vue-tsc + build 通过);Console 28 → 54(19 个文件)。
另修复一条会让整包挂死 600s 的用例(测试主协程堵在 client.Do,defer
轮不到执行 → 改为可取消 + 探针超时,改坏也 7.5s 快速失败)。
## 两个新守卫(防止再出现「组件 setup 抛异常」这类盲区)
- `web/scripts/check-declaration-order.mjs` 已进测试命令:沿 watch/
watchEffect 的 const 依赖链查 TDZ(正是「运动员页整块空白」的根因)
- `web/scripts/smoke-admin.mjs`(`pnpm smoke`):真 Chromium 点遍 14 个
管理端路由 + 7 个基础数据分区 + 大屏页,任何 console 错误即失败
## 文档
- `docs/升级说明.md` 新增 dev_0.2.0 一节(三件升级必知:改名、审计前缀
与历史记录、密码口径;现场变化;赛事包上限;反代与 CSRF)
- 使用手册 / 常见问题 / 部署指南 / 上线检查清单按实现同步
124 lines
5.2 KiB
JavaScript
124 lines
5.2 KiB
JavaScript
'use strict'
|
||
|
||
const fs = require('fs')
|
||
const path = require('path')
|
||
|
||
// 数据目录必须落在安装目录之外:electron-builder 的卸载器结尾是 `RMDir /r $INSTDIR`,
|
||
// 而覆盖安装会先静默跑一遍旧版卸载器 → 装在安装目录里的 data/ 会被整体删掉。
|
||
// 也不能放 %APPDATA%\<AppName>(卸载器同样会删),所以默认落在 %LOCALAPPDATA%\ScoreboardConsole\data。
|
||
// 配置与规则目录(userpaths.js)用同一个基座,这里导出给它复用。
|
||
const LOCAL_BASE = 'ScoreboardConsole'
|
||
const DATA_SUBDIR = 'data'
|
||
|
||
// 解析最终数据目录。installDir 是安装目录(打包后 = exe 所在目录),
|
||
// 相对路径按安装目录解析,现场写 `data`、`D:\scoreboard-data` 都能用。
|
||
// passToServer=false 表示不给服务端加 -data,沿用服务端自身默认(开发态)。
|
||
function resolveDataDir({ values, installDir, env, isPackaged }) {
|
||
const base = path.resolve(installDir || '.')
|
||
const configured = values && values.server ? values.server.dataDir : ''
|
||
|
||
if (typeof configured === 'string' && configured.trim() !== '') {
|
||
const value = configured.trim()
|
||
return {
|
||
dir: path.isAbsolute(value) ? path.resolve(value) : path.resolve(base, value),
|
||
source: 'config',
|
||
passToServer: true
|
||
}
|
||
}
|
||
|
||
// 开发态不接管:继续用服务端默认(工作目录下的 data),免得仓库里的 data/ 被顶掉
|
||
if (!isPackaged) {
|
||
return { dir: path.join(base, DATA_SUBDIR), source: 'default', passToServer: false }
|
||
}
|
||
|
||
const localAppData = env ? env.LOCALAPPDATA : ''
|
||
if (!localAppData) {
|
||
// 拿不到 %LOCALAPPDATA% 时退回老位置:这次覆盖安装仍有丢数据风险,
|
||
// 但总好过把数据指向一个猜出来的路径
|
||
return { dir: path.join(base, DATA_SUBDIR), source: 'fallback', passToServer: false }
|
||
}
|
||
|
||
return {
|
||
dir: path.join(localAppData, LOCAL_BASE, DATA_SUBDIR),
|
||
source: 'localappdata',
|
||
passToServer: true
|
||
}
|
||
}
|
||
|
||
// 判断 dir 是否落在 base 之内(含 base 本身):用于提醒「数据还在安装目录里」,
|
||
// 这种配置在覆盖安装时会被卸载器连目录一起删掉
|
||
function isInside(base, dir) {
|
||
const rel = path.relative(path.resolve(base), path.resolve(dir))
|
||
return rel === '' || (!rel.startsWith('..') && !path.isAbsolute(rel))
|
||
}
|
||
|
||
// missing = 不存在,empty = 存在但空,has-data = 有内容
|
||
// 读不出来时返回 error,由调用方按「可能有数据」处理,宁可不迁移
|
||
function dirState(dir) {
|
||
let entries
|
||
try {
|
||
entries = fs.readdirSync(dir)
|
||
} catch (err) {
|
||
return err.code === 'ENOENT' ? 'missing' : 'error'
|
||
}
|
||
return entries.length > 0 ? 'has-data' : 'empty'
|
||
}
|
||
|
||
// 一次性迁移:只在「目标为空且旧目录有数据」时把旧目录整体改名过去。
|
||
// 任何一步失败都只记日志、旧数据保持原地,绝不删除数据;
|
||
// 两边都有数据时不做任何动作,只提示现场人工确认。
|
||
function migrateLegacyData({ targetDir, legacyDir, log }) {
|
||
const notify = typeof log === 'function' ? log : () => {}
|
||
if (!targetDir || !legacyDir) return { migrated: false, reason: 'invalid' }
|
||
if (path.resolve(targetDir) === path.resolve(legacyDir)) return { migrated: false, reason: 'same-dir' }
|
||
|
||
const target = dirState(targetDir)
|
||
const legacy = dirState(legacyDir)
|
||
|
||
if (target === 'error') {
|
||
notify(`警告:读不到数据目录 ${targetDir},跳过旧数据迁移;旧数据仍在 ${legacyDir}`)
|
||
return { migrated: false, reason: 'target-unreadable' }
|
||
}
|
||
|
||
// 旧目录读不出来(EACCES / EPERM / ENOTDIR 等)与「没有旧数据」是两回事:
|
||
// 前者可能是一份没搬成功的真实数据,不能静默按「没数据」处理,必须留一条日志让人去人工确认。
|
||
if (legacy === 'error') {
|
||
notify(
|
||
`警告:读不到旧数据目录 ${legacyDir}(权限不足或路径不可用),本次不做迁移。` +
|
||
'请人工确认该目录里是否有需要保留的数据'
|
||
)
|
||
return { migrated: false, reason: 'legacy-unreadable' }
|
||
}
|
||
|
||
if (target === 'has-data') {
|
||
if (legacy === 'has-data') {
|
||
notify(
|
||
`警告:旧数据目录 ${legacyDir} 与新数据目录 ${targetDir} 都有数据,未做迁移。` +
|
||
'请人工确认要保留哪一份(两份都不会被自动删除)'
|
||
)
|
||
return { migrated: false, reason: 'both' }
|
||
}
|
||
return { migrated: false, reason: 'target-has-data' }
|
||
}
|
||
|
||
if (legacy !== 'has-data') return { migrated: false, reason: 'no-legacy' }
|
||
|
||
try {
|
||
// Windows 上 rename 到已存在的目录会失败,先摘掉这个空目录(空目录里没有数据)
|
||
if (target === 'empty') fs.rmdirSync(targetDir)
|
||
fs.mkdirSync(path.dirname(targetDir), { recursive: true })
|
||
fs.renameSync(legacyDir, targetDir)
|
||
} catch (err) {
|
||
notify(
|
||
`警告:迁移旧数据失败(${err.message}),旧数据仍保留在 ${legacyDir};` +
|
||
`本次服务端将使用 ${targetDir},请人工把旧目录内容拷过去`
|
||
)
|
||
return { migrated: false, reason: 'failed' }
|
||
}
|
||
|
||
notify(`已把旧数据从 ${legacyDir} 迁移到 ${targetDir}`)
|
||
return { migrated: true, reason: 'moved' }
|
||
}
|
||
|
||
module.exports = { resolveDataDir, migrateLegacyData, isInside, LOCAL_BASE }
|