直接回答：治理分两步：先止血（找出并清掉大头），再建机制（预算门禁防复发）。止血靠分析工具（source-map-explorer、rollup-plugin-visualizer）看产物构成，高频大头：重复打包的依赖（多个版本共存）、整库引入（lodash、moment、全量 antd 图标）、误打包的服务端依赖、图片内联 base64、未按路由拆包。
展开解析：具体手段：lodash 换 lodash-es 并确认 tree-shaking 生效（sideEffects 标记与 ESM 前提），moment 换 dayjs 或 Intl；组件库确认按需引入而非 babel-plugin-import 失效后的全量；动态 import() 做路由级与重交互组件（编辑器、图表）级拆包；依赖治理用 npm dedupe、resolutions 收敛版本，duplicate 检测进 CI。机制建设是重点：CI 里跑 size-limit 或自定义脚本，产物体积与预算 diff 评论到 MR，超预算要求说明或拆分；把首屏 JS 总量（gzip 后）作为北极星指标，按路由设子预算；定期生成体积趋势报告（接入构建产物上报），让膨胀可见。认知上要让团队理解：体积是复利模型——每人每次加 5KB 无感，一年加 300KB 灾难，所以防线必须自动化而非靠评审自觉。框架层也有杠杆：SSR/RSC 把数据获取与重组件挪到服务端、islands 架构只给交互岛注水，是结构性减重而非挤牙膏。
追问方向：tree-shaking 失效的常见原因？如何验证拆包策略是否真提升了 LCP？
（约 480 字）