Appearance
Tree Shaking 与 Code Splitting：删掉不用的代码和推迟加载不是一回事
问题背景
这两个概念经常一起出现，但分别解决的是包体积和加载时机。
- 这两个概念经常一起出现，但分别解决的是包体积和加载时机
- Tree Shaking 关注静态可判定的无用导出删除；Code Splitting 关注模块图按入口和动态边界切分
- 它们都会影响体积和首屏，但机制完全不同
- CommonJS、动态访问导出、全局副作用初始化都会削弱 Tree Shaking
- Tree Shaking 依赖 ESM 静态导入导出关系、无副作用判定和压缩阶段的 dead code elimination
指标、症状与判断信号
- 这两个概念经常一起出现，但分别解决的是包体积和加载时机
- Tree Shaking 关注静态可判定的无用导出删除；Code Splitting 关注模块图按入口和动态边界切分
- 它们都会影响体积和首屏，但机制完全不同
- CommonJS、动态访问导出、全局副作用初始化都会削弱 Tree Shaking
- Tree Shaking 依赖 ESM 静态导入导出关系、无副作用判定和压缩阶段的 dead code elimination
常见方案空间
- 追问通常会沿着 性能指标、监控和治理闭环 展开，重点在于把现象还原成系统行为
- 优化包体积时要同时看静态删除率、chunk 图、共享依赖重复率和首屏实际执行量
- 有过线上问题或性能治理经历时，补充你如何定位 性能指标、监控和治理闭环、如何验证假设，以及如何收敛风险
- 偏设计题需要补充未选方案的放弃原因，以及 大列表、分包和发布策略 最终如何影响方案落地
- 这类问题更适合讲方案空间，而不是讲单点工具
- 治理意味着要同时承担成本控制、优先级排序和长期维护
取舍、闭环与治理代价
- Tree Shaking 关注静态可判定的无用导出删除；Code Splitting 关注模块图按入口和动态边界切分
- 治理意味着要同时承担成本控制、优先级排序和长期维护
- 组件库和业务模块都应明确副作用边界，否则构建工具无法安全删除代码
- 跨团队协作时，要补充责任边界、数据口径和回归标准
落地路径与协作方式
- 治理题最好按“发现问题 -> 定位归因 -> 实施动作 -> 验证结果 -> 持续追踪”的顺序去讲
- 跨团队协作时要补充责任边界、数据口径和回归标准
- 越偏线上治理，越要说明发布、回滚、灰度、告警和版本信息如何联动
问答设计及延伸
标准回答
回答 Tree Shaking 与 Code Splitting：删掉不用的代码和推迟加载不是一回事 时，先定义要治理的症状，再给出方案空间和取舍依据，最后交代闭环如何落地以及结果如何验证。
追问拆解
- Tree Shaking 与 Code Splitting：删掉不用的代码和推迟加载不是一回事 与“Vite 构建链路：开发服务器、预构建与生产产物”分别落在治理闭环的哪一步
- Tree Shaking 与 Code Splitting：删掉不用的代码和推迟加载不是一回事 与“HTTP 版本演进：HTTP/1.1、HTTP/2、HTTP/3 各解决了什么”分别落在治理闭环的哪一步
- 预算和人力受限时的保序优先级
- 数据与用户感知冲突时的判定口径
容易失分的点
- 只报工具名，不讲问题背景和指标口径
- 只讲发现问题，不讲如何验证和收敛
- 把治理说成一次性动作，而不是持续机制