fix(admin): 管理端入口收敛到 /admin/ 子路径，staging 端口 13521，修复生产 /admin/ 假成功
承接 rc.15 的管理端端口收敛（3000 → 13520），本轮把「入口」也收敛到一处： - staging admin 发布端口 3001 → 13521（保持「生产 + 1」错开），同步 tests/uat/run-uat.sh 的默认 UAT_ADMIN_URL。 - 管理端产物改为 /admin/ 子路径部署：vite 构建 base=/admin/（dev 仍为 /，开发与 排查习惯不变）、router history base 跟随 import.meta.env.BASE_URL、三处容器化 入口（生产 nginx / 本地整套栈 nginx / admin-web 容器内 nginx）统一为「不剥离 前缀」转发，形态一致。 - 修复生产 nginx /admin/ 的假成功：原为 alias /usr/share/nginx/html/，而那正是 nginx:alpine 纯净镜像自带的默认页目录（管理端产物不在该容器内），访问返回 200 + nginx 欢迎页 —— 浏览器不报错、状态码正常，只是打开的不是管理端，比 404 更难发现。改为 upstream admin_web + proxy_pass，并以真实两跳容器实测： /admin/ → 200 且为管理端标题与 /admin/assets/*、/admin/dashboard → 200（SPA 兜底）、/admin/brand/logo-mark.png → 200、根路径 → 显式 404（用 location = / 钉住，不依赖「本配置恰好没有 server 级 root」这一偶然事实）。 - 品牌资源引用统一走新增的 src/brand.ts（public/ 资源不受 vite base 影响，原 5 处 写死根路径，子路径部署下会裂图）；favicon 由仓库内并不存在的 /favicon.svg 改为 存在的品牌标。 - 补全 tests/uat/run-uat.sh 被截断的尾部：原文件停在 `if [ -`，bash -n 不通过、 脚本根本无法运行；顺带把此前「定义了却无人消费」的 ADMIN_URL 接到管理端可达性 实测上，并补结果汇总与非零退出码。 - ui-tests：ui-document-baseline-contracts 新增两类一致性断言（staging 发布端口 ⇄ run-uat.sh 默认入口、子路径部署的五处约束）；admin-reference-contracts 的资产 断言适配 brand 模块（断言「组件经 brand 模块引用」+「brand 模块指向正式资产」）。 6 条新增断言全部经负向注入验证（注入对应缺陷 → 守卫变红且信息指向正确对象）。 验证：UI 门控 14/14 绿；vue-tsc EXIT=0；vite build EXIT=0 且产物资源均为 /admin/ 前缀；三份 nginx 配置 nginx -t 通过。 注：docs/STATUS.md 含此前的在途文档改动（非本次工作，且其中引用了已被删除的 plans 文件），故未纳入本提交；本轮的口径更新已写入该文件待一并处理。
This commit is contained in:
WorkBuddy
@@ -7,6 +7,10 @@ const read = (path) => readFileSync(resolve(root, path), 'utf8')
|
||||
const theme = read('admin-web/src/theme/index.css')
|
||||
const layout = read('admin-web/src/layouts/MainLayout.vue')
|
||||
const dashboard = read('admin-web/src/views/DashboardView.vue')
|
||||
// 品牌资产的实际文件名集中在 src/brand.ts：public/ 下的资源不受 vite base 影响，
|
||||
// 引用时必须显式拼 BASE_URL（否则在 /admin/ 子路径部署下 404）。因此下面断言
|
||||
// 「组件经 brand 模块引用」+「brand 模块指向正式资产」两处，而不是在组件里找文件名字面量。
|
||||
const brand = read('admin-web/src/brand.ts')
|
||||
|
||||
for (const token of [
|
||||
'--admin-coral',
|
||||
@@ -27,7 +31,8 @@ assert.ok(
|
||||
for (const className of ['admin-scene', 'admin-shell', 'admin-sidebar', 'admin-topbar', 'admin-content']) {
|
||||
assert.ok(layout.includes(className), `缺少框架结构 ${className}`)
|
||||
}
|
||||
assert.match(layout, /admin-danyang-backdrop\.jpg/, '管理端外层未使用正式背景资产')
|
||||
assert.match(brand, /admin-danyang-backdrop\.jpg/, '品牌模块未指向正式背景资产')
|
||||
assert.match(layout, /BRAND_BACKDROP/, '管理端外层未使用正式背景资产')
|
||||
assert.match(layout, /permissions/, '侧栏未保留权限控制')
|
||||
|
||||
for (const item of [
|
||||
@@ -60,7 +65,8 @@ assert.match(dashboard, /metrics/, '工作台缺少指标数据绑定')
|
||||
assert.match(dashboard, /Asia\/Shanghai/, '工作台日期未固定为中国时区')
|
||||
assert.match(dashboard, /loadDashboard/, '工作台未接入真实数据适配层')
|
||||
assert.match(dashboard, /retryLoad/, '工作台缺少失败重试')
|
||||
assert.match(dashboard, /activity-default\.jpg/, '活动封面缺少本地降级资产')
|
||||
assert.match(brand, /activity-default\.jpg/, '品牌模块未指向活动封面降级资产')
|
||||
assert.match(dashboard, /BRAND_ACTIVITY_FALLBACK/, '活动封面缺少本地降级资产')
|
||||
assert.match(dashboard, /item\.max\s*>\s*0/, '成效进度未处理 max 为 0 的情况')
|
||||
assert.match(dashboard, /v-for="metric in dashboard\.metrics"/, '六指标必须由 DashboardModel 统一渲染')
|
||||
|
||||
|
||||
@@ -78,13 +78,13 @@ assert.doesNotMatch(matrix, /63 个页面.*(全部|全量).*重构/, '页面矩
|
||||
// 前两处（vite / STATUS）是版本控制内的硬断言；第三处（生产 compose）只能
|
||||
// 「存在才断言」，因为它被刻意排除在版本控制之外 —— 理由见下。
|
||||
//
|
||||
// 刻意不纳入守卫的另外两处「管理端入口」，它们是不同形态，不是同一端口的失联：
|
||||
// 刻意不纳入本组守卫的另一处「管理端入口」：
|
||||
// - infrastructure/docker-compose.yml：admin 容器不发布端口，管理端经 nginx 的 6688
|
||||
// 与 /api 一起暴露（6688 是 nginx 入口端口，不是纯管理端端口）；
|
||||
// - infrastructure/docker-compose.staging.yml：staging 需与生产同机共存，
|
||||
// 全部端口按「生产 + 1」错开（5433/6380/8081/3001），且 3001 被
|
||||
// tests/uat/run-uat.sh 的 UAT_ADMIN_URL 依赖。
|
||||
// 改动这些入口时应同步其消费方，而不是让本守卫去断言它们等于 vite 端口。
|
||||
// 与 /api 一起暴露（6688 是 nginx 入口端口，不是纯管理端端口），故不参与"等于 vite 端口"。
|
||||
// staging（docker-compose.staging.yml）原也列在"不纳入"——它按「生产 + 1」错开，端口本就不
|
||||
// 等于 vite 端口。但它与 tests/uat/run-uat.sh 默认值之间的一致性是可断言的（两者都在版本
|
||||
// 控制内），而两者不一致正是"照脚本去跑、管理端却打不开"的直接原因，故改为单独一组断言：
|
||||
// 见下方「staging 管理端入口一致性」。
|
||||
const viteConfig = read('admin-web/vite.config.ts')
|
||||
const vitePort = viteConfig.match(/^\s*port:\s*(\d+),/m)?.[1]
|
||||
// 解析失败即失败：正则匹配不到时捕获组为 undefined，断言会退化成"与 undefined 比较"
|
||||
@@ -125,4 +125,101 @@ if (!existsSync(resolve(root, prodComposePath))) {
|
||||
)
|
||||
}
|
||||
|
||||
// —— staging 管理端入口一致性（发布端口 / UAT 脚本默认值 / 子路径） ——
|
||||
// 2026-09-18 之前，tests/uat/run-uat.sh 里的 ADMIN_URL 是个「定义了却无人消费」的常量：
|
||||
// 端口改了、脚本没同步，不会有任何检查变红。现该变量已接到实测的管理端可达性检查上，
|
||||
// 这里再用门控保证它与 staging compose 的发布端口一致 —— 否则实测会稳定地测错对象。
|
||||
const stagingCompose = read('infrastructure/docker-compose.staging.yml')
|
||||
const stagingAdminMapping = stagingCompose
|
||||
.match(/container_name:\s*danyang-match-staging-admin\n([\s\S]*?)(?=\n {2}[a-z]|$)/)?.[1]
|
||||
?.match(/-\s*"([^"]+)"/)?.[1]
|
||||
assert.ok(stagingAdminMapping, '未能从 docker-compose.staging.yml 的 admin-web 解析出端口映射（守卫自身失效）')
|
||||
const stagingAdminPort = stagingAdminMapping.split(':').at(-2)
|
||||
|
||||
const uatAdminUrlMatch = read('tests/uat/run-uat.sh')
|
||||
.match(/^ADMIN_URL="\$\{UAT_ADMIN_URL:-http:\/\/localhost:(\d+)(\/[^}"]*)?\}"/m)
|
||||
assert.ok(uatAdminUrlMatch, '未能从 tests/uat/run-uat.sh 解析出 ADMIN_URL 默认值（守卫自身失效）')
|
||||
assert.equal(
|
||||
uatAdminUrlMatch[1],
|
||||
stagingAdminPort,
|
||||
`管理端 UAT 入口端口不一致：run-uat.sh=${uatAdminUrlMatch[1]}，docker-compose.staging.yml=${stagingAdminPort}`,
|
||||
)
|
||||
// 子路径：产物部署在 /admin/ 下，UAT 入口必须带该前缀。缺了它测的是根路径（301 或 404）——
|
||||
// "检查了但检查错了对象"比不检查更坏，因为它给出的是通过。
|
||||
assert.equal(uatAdminUrlMatch[2], '/admin/', `run-uat.sh 的管理端入口未指向 /admin/ 子路径：${uatAdminUrlMatch[0]}`)
|
||||
// staging 与生产同机共存，端口必须错开。生产端口在 CI 上不可知（prod compose 不在版本
|
||||
// 控制内），故只能断言"不撞车"，不断言具体的「生产 + 1」。
|
||||
assert.notEqual(stagingAdminPort, vitePort, `staging 管理端端口与主管理端端口撞车（都是 ${stagingAdminPort}），同机部署会冲突`)
|
||||
|
||||
// —— 管理端子路径部署一致性 ——
|
||||
// 产物部署在 /admin/ 子路径下（vite base 按 command 分叉）。该形态依赖五处同时成立：
|
||||
// vite base、router history base、生产 nginx、本地整套栈 nginx、admin-web 容器自身 nginx。
|
||||
// 任一处退回根路径假设，都会造成"页面能打开但白屏 / 裂图 / 指到别的东西"。
|
||||
// 历史缺陷：生产 nginx 的 /admin/ 曾写 `alias /usr/share/nginx/html/` —— 那是 nginx:alpine
|
||||
// 镜像自带的默认页目录（本容器内并没有管理端产物），于是 /admin/ 返回 200 + nginx 欢迎页：
|
||||
// 假成功，比 404 更难发现。故下面既断言"代理到 upstream"，也反向断言"不得再退回 alias"。
|
||||
assert.match(
|
||||
viteConfig,
|
||||
/base:\s*command\s*===\s*'build'\s*\?\s*'\/admin\/'\s*:\s*'\/'/,
|
||||
'vite 未把构建 base 设为 /admin/（产物会引用站点根路径的资源）',
|
||||
)
|
||||
assert.match(
|
||||
read('admin-web/src/router/index.ts'),
|
||||
/createWebHistory\(import\.meta\.env\.BASE_URL\)/,
|
||||
'router 的 history base 未跟随 vite base（子路径部署下刷新或直达深层路由会白屏）',
|
||||
)
|
||||
|
||||
const prodNginx = read('infrastructure/nginx-production.conf')
|
||||
assert.match(prodNginx, /upstream\s+admin_web\s*\{[\s\S]*?server\s+admin-web:80;/, '生产 nginx 未声明 admin_web upstream')
|
||||
assert.match(
|
||||
prodNginx,
|
||||
/location\s+\/admin\/\s*\{[^}]*proxy_pass\s+http:\/\/admin_web;/,
|
||||
'生产 nginx 的 /admin/ 未代理到 admin_web upstream',
|
||||
)
|
||||
assert.doesNotMatch(
|
||||
prodNginx,
|
||||
/location\s+\/admin\/\s*\{[^}]*alias\s/,
|
||||
'生产 nginx 的 /admin/ 又退回 alias 本容器目录（会返回镜像默认页，属假成功）',
|
||||
)
|
||||
|
||||
assert.match(
|
||||
read('infrastructure/nginx.conf'),
|
||||
/location\s+\/admin\/\s*\{[^}]*proxy_pass\s+http:\/\/admin_web;/,
|
||||
'本地整套栈 nginx 的 /admin/ 未代理到 admin_web（6688 上取不到管理端）',
|
||||
)
|
||||
|
||||
const adminContainerNginx = read('admin-web/nginx-admin.conf')
|
||||
assert.match(
|
||||
adminContainerNginx,
|
||||
/location\s+\/admin\/\s*\{[\s\S]*?alias\s+\/usr\/share\/nginx\/html\/;/,
|
||||
'admin-web 容器 nginx 未服务 /admin/ 子路径',
|
||||
)
|
||||
assert.match(
|
||||
adminContainerNginx,
|
||||
/try_files\s+\$uri\s+\$uri\/\s+\/admin\/index\.html;/,
|
||||
'admin-web 容器 nginx 的 SPA 兜底未指向 /admin/index.html（alias 配 try_files 写成文件路径会失效）',
|
||||
)
|
||||
|
||||
// public/ 下的运行时资源不受 vite base 影响（原样复制到产物根），因此写死 `src="/brand/...`
|
||||
// 或 `url('/brand/...')` 在子路径部署下会 404（logo / 插画 / 背景图裂）。统一走 src/brand.ts。
|
||||
for (const file of [
|
||||
'admin-web/src/layouts/MainLayout.vue',
|
||||
'admin-web/src/views/LoginView.vue',
|
||||
'admin-web/src/views/DashboardView.vue',
|
||||
]) {
|
||||
const src = read(file)
|
||||
assert.doesNotMatch(src, /src="\/brand\//, `${file} 仍写死 /brand/ 根路径引用（子路径部署下会裂图）`)
|
||||
assert.doesNotMatch(src, /url\('\/brand\//, `${file} 仍写死 url('/brand/...')（子路径部署下会裂图）`)
|
||||
}
|
||||
assert.match(
|
||||
read('admin-web/index.html'),
|
||||
/href="\/brand\/logo-mark\.png"/,
|
||||
'index.html 的 favicon 未指向存在的品牌资源（vite 会为它补上 base 前缀）',
|
||||
)
|
||||
assert.doesNotMatch(
|
||||
read('admin-web/index.html'),
|
||||
/favicon\.svg/,
|
||||
'index.html 仍引用不存在的 /favicon.svg（仓库内无此文件，且绝对路径不随 base 变化）',
|
||||
)
|
||||
|
||||
console.log('UI document baseline contracts passed')
|
||||
|
||||
Reference in New Issue
Block a user