企业官网建设流程全解析

构建链路试验出问题后，先把证据和变更收起来

让自动化工具分析 Vite 产物、提出分包建议是可行的，但“建议”与“直接改配置”之间隔着一条很长的安全线。构建配置会影响模块解析、动态导入、资源路径和缓存命名。一次看起来合理的分组调整，可能只在某种路由、某个部署前缀或某个浏览器缓存状态下出错。

发布后出现资源加载失败或产物突然变大时，第一件事不是给某个工具定性，而是固定现场。保留本次提交、锁文件、完整的最终配置、构建日志、产物清单和部署环境信息。没有这些材料，后来很难判断是配置改动、依赖升级、缓存差异还是发布流程造成的结果。

自动修改必须可追溯、可回滚

若工具可以提出 Vite 配置变更，最好把结果落成一份普通的变更提议，而不是在构建过程中静默覆写配置。提议里应说明改了哪些字段、依据是什么、影响的入口和 chunk 是什么。它进入代码审查后，仍由开发者决定是否合并。

即便允许自动应用，也要把改动限定在专门的配置片段，并保存前后版本。不要让工具用宽泛的文本替换去修改 import、插件顺序或 Rollup 输出字段。构建配置不是纯文本模板，一个误匹配就可能破坏动态导入或把本该独立的模块塞进主包。

回滚也不能只靠“再跑一次构建”。要能明确回到哪个已知配置版本，并在相同依赖与环境下重新产出。锁文件变了、Node 版本变了、缓存命中不同，都可能让两次对比失真。

先判断异常出在构建还是部署

页面资源 404 不一定是分包逻辑的问题。检查顺序可以从最终 HTML 中的资源地址开始：部署前缀是否正确、产物文件是否真的上传、服务器是否把 history fallback 误用于静态文件、缓存层是否仍指向旧 HTML。然后再看 manifest、入口 chunk 和动态导入的引用关系。

产物体积增长也需要拆开看。是某个入口变大，还是总文件数变多；增长的是原始字节还是压缩后大小；新增内容是业务代码、依赖还是 source map。只看一个“总大小”很容易把正常的功能增量当成异常，或漏掉真正的重复依赖。

构建日志应记录最终生效的插件顺序、关键输出配置、每个入口及其依赖关系。日志不需要把全部源码打印出来，但要让人能将一次产物追溯到一次配置和一次提交。对于容易造成副作用的插件，还可以给它们加上明确的启用条件，默认在实验分支或预发布环境中运行。

用基线做比较，而不是只设一个绝对阈值

体积预算有用，但绝对上限只能发现一部分问题。更敏感的是与上一个已验证构建比较：主入口为何增长、哪些依赖从异步 chunk 移入了首屏、是否出现同一库的多个版本。基线也必须与分支和目标环境对应，不能拿开发构建去和生产构建比较。

预算触发后，CI 给出的信息要足够具体：违规的是哪个文件、当前大小和基线差多少、使用的是原始还是压缩口径、是否存在豁免记录。开发者需要据此判断是拆分代码、按需加载、替换依赖，还是更新经过评审的预算。

不要让体积检查偷偷修改构建结果。检查器只负责报告和阻断，优化动作仍在可审查的配置里完成。这种分工看似保守，却能让发布失败时的责任链更短。

试验应有退出机制

为自动化分析准备一组稳定的代表性项目或 fixture，覆盖动态导入、CSS、静态资源、多个入口和常用插件。每次算法或提示词改变，先在这些样本上比较输出，再进入真实项目。出现异常时，开关应能立即关闭自动应用，而保留分析和日志功能，避免为了止血把证据也一起关掉。

构建系统的目标是可重复地产出可部署文件。任何试图优化它的自动化能力，都应服从这个目标：改动有记录，结果有对照，失败可回退。这样即使实验没有带来收益，也能清楚知道它在哪一步不适合继续使用。