宋瑞 · Frontend

Appearance

前端工程化：质量门禁与可重复交付 ​

工程化不是工具清单，而是缩短“发现问题—定位原因—验证修复”的反馈周期。一个成熟项目应让本地和 CI 的行为尽量一致，并能回答“这次发布包含什么、如何验证、怎么回滚”。

一条可解释的流水线 ​

text
PR 快速门禁
  ├─ frozen install / 依赖完整性
  ├─ lint + format check
  ├─ typecheck
  ├─ unit / component test
  └─ production build

主干与发布
  ├─ 完整测试 + E2E 关键链路
  ├─ 产物/依赖/安全分析
  ├─ 生成不可变产物与版本清单
  ├─ 灰度与健康检查
  └─ 指标观察 / 回滚

PR 反馈要快，主干可以做更完整验证。失败日志要能定位到任务、文件和产物，而不只是“exit 1”。

依赖与锁文件 ​

锁文件必须提交，CI 使用 frozen/clean install。本博客原来同时存在 package-lock.json 和 yarn.lock，它们可能产生两套依赖图，无法保证可重复构建；项目应明确唯一包管理器。

升级依赖时先看 changelog、Node 引擎和破坏性变化，再让类型检查、测试、构建和 bundle diff 共同验证。安全告警需结合是否可达、运行环境和影响决定升级、替换或记录接受风险。

配置与秘密 ​

任何进入前端构建产物的变量最终都能被用户看到，VITE_ 前缀不是秘密保护。只暴露必要的公开配置，服务端密钥永远不进入浏览器包；环境差异优先在部署/运行时配置管理，并对 schema 做校验。

测试金字塔按风险落地 ​

  • 纯函数、Store、composable：快速单测，覆盖状态转移与边界。
  • 组件：验证用户可见行为、错误态、权限态与可访问性。
  • E2E：少量覆盖登录、购买、发布等关键链路，并隔离测试数据。

覆盖率不是目标本身。一个权限状态机的关键分支测试，比大量只断言内部实现的快照更有价值。

发布和回滚 ​

同一提交只构建一次，产物晋级到各环境，避免“测试环境通过、生产重新构建后变了”。HTML 与静态 chunk 的缓存策略要配套；回滚不能只回 HTML，还要保证它引用的旧 chunk 仍然可用。

本博客的改造清单 ​

  • VitePress 从 RC 升级到稳定版，并以生产构建验证旧内容。
  • 移除外部图标样式 CDN，降低隐私、可用性和阻塞风险。
  • 增加本地搜索、sitemap、语义化首页与招聘者导向导航。
  • Nginx 配置 gzip_static，让构建生成的 .gz 真正被服务。
  • HTML 使用 no-cache，哈希静态资源长期缓存。

工程化的最终证据应是更少的版本漂移、更快的反馈和更可控的故障，而不是配置文件更长。