共享前端包与 CI 交付边界

多个网站和管理后台复用认证、表格搜索、图片上传或结账字段规则时，复制代码最初很快，后续却会让同一处错误在不同项目里反复出现。共享包能解决这一类重复，但前提是它提供稳定、足够小的公共接口，而不是把某个业务项目整体搬进去。

先判断什么值得共享

适合抽取的代码通常满足两个条件：多个项目已经用到同一规则，并且这些项目期望规则保持一致。对于变化节奏不同的业务页面、专属样式和只用一次的封装，暂时留在应用内更容易维护。

例如，姓名规范化函数可以约定输入、输出和空值行为，再供不同结账页使用；而“如何排列某个酒店页面的旅客表单”仍属于应用层。共享包只负责规则，页面决定交互。

公共接口比内部结构重要

• 从包的公开入口导出稳定能力，避免消费者直接引用内部文件路径。
• 明确必填输入、返回值和错误语义；不要让调用方猜测函数是否会修改传入对象。
• 为中文、英文及混合姓名等边界情况写测试。若业务规则有地区差异，把差异作为明确参数或独立策略，而不是在包内猜测使用者。
• 依赖浏览器 API 的工具应标明运行环境，不能在服务端渲染时访问 window。

发布新版本时先看消费者：更改字段名或默认行为即使没有改函数签名，也可能是破坏性变更。共享包的变更应附带一两个真实消费项目的验证结果。

CI 应验证交付物

一条实用的前端流水线可以按反馈速度安排：格式与类型检查、单元测试、构建、打包检查，再运行关键浏览器路径。私有包认证只在需要安装或发布的任务中注入令牌，不写进仓库、构建产物或日志。

浏览器测试分片可以缩短耗时，但分片之间不能共用会互相修改的账号和数据。失败时保留截图、追踪文件和测试报告，才能判断是页面回归、接口故障，还是环境不稳定。单纯重跑到通过会掩盖偶发错误。

打包检查应关注真正会交给消费者的文件：类型声明、入口文件、样式和必要资源是否存在；内部测试、密钥和本地配置是否被排除。源码库里构建成功，不等于发布包可以被另一个项目正常导入。

发布与回滚一起设计

前端页面与静态资源可能经过不同缓存层。新 HTML 若引用尚未上传的资源会白屏；旧 HTML 若引用已被删除的资源，也会在版本交错时失败。部署顺序应先保证新资源可取，再切换入口，并让带哈希的旧资源保留足够时间。

回滚时不要只检查服务进程是否存活，还要打开关键页面、加载资源并走一条真实操作路径。CI 证明的是候选版本满足构建和测试条件；目标环境是否生效，需要另行验证。