内部管理后台接入自动化构建发布流水线

为什么做

管理后台前端以前是手工构建 + 手工发布：在本地跑构建，把产物 rsync 上服务器。

这条路在过去几个月踩了两个大坑：

• 用错了历史目录做构建，导致产物 hash 对不上，线上登录页样式崩溃
• 构建流程在特定情况下只编译了框架默认代码，项目自定义源码没进产物，线上跑的其实是一套无用的 demo

这两个坑最终促使我们把整套构建发布流程自动化。

做了什么

1. GitHub Actions 自动化流水线

开发者只需要修改 web-antd/src/ 下的源码并推送到主分支，CI 会自动：

1. 检出仓库
2. 准备构建环境
3. 覆盖项目自定义源码到 monorepo 构建基础
4. 安装依赖
5. 执行构建
6. 同步构建产物到发布目录
7. 提交并部署到服务器

整个流程约 4 分钟完成。

2. 构建产物验证

CI 构建流程里增加验证步骤，检查关键文件是否被正确覆盖。如果验证失败，CI 立即中止，不会部署错误产物。这一条是针对此前踩过的"构建成功但产物是空壳"的坑。

3. 显式声明运行时依赖

项目历史上有些依赖是"隐式依赖"——凭巧合能跑，但在独立构建环境里会缺失。这次一次性把缺失的依赖都显式声明，避免 CI 构建到一半因为找不到依赖挂掉。

4. Nginx 配置修正

管理后台访问后端接口时曾经出现"全部接口都提示跨域"的情况，根因是 Nginx 全局配置导致 404 响应丢失 CORS 头。这次也一并修复。

用户会感受到的变化

这条更新对普通用户的直观感知偏弱，但长期影响非常实在：

• 内部人员修完问题，几分钟内就能到达用户端，不需要等"谁在哪台电脑上构建一下"
• 线上基本不会再出现"昨天还好好的今天样式崩了"的情况
• 管理效率提升之后，老孙有更多时间做内容和辅导本身，而不是处理发布流程

相关范围

• 内部工具：管理后台前端构建与发布流程
• 底层保障：整个站点的发布稳定性

这条记录的发布时间

以最后一次相关 git 提交的时间为准：2026-04-14 15:53:11。