部署与运行
构建Build
你可能会问
构建到底是什么？代码写完了，为什么还要「构建」一步？
简单来说
把源代码转换、打包成可以在目标环境运行或发布的产物。
源代码 · 给人读的
main.tsTypeScript · 300 个文件
依赖引用几十个库
从给人读，到给机器跑
01 · 先这样理解
把抽象概念放进真实场景
把源代码转换、打包成可以在目标环境运行或发布的产物。
换个角度想构建像把菜谱变成能上桌的菜：菜谱（源码）人看得懂但不能直接吃；按菜谱备料、烹饪、装盘（构建），才是能端出去的东西。
02 · 点击演示
写好的代码，怎么变成线上能跑的东西？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 这次要上线的
源码改了 5 个文件新依赖装了一个图表库 跳过本地构建
问题被原样带向线上
构建报错：图表库没进依赖清单
✓ 上线前就被拦下
线上构建到一半失败
部署中断 · 网站还是旧版
修好后重新构建产物dist/ · 3 个文件体积压缩后只剩零头- 发布推迟半夜排查依赖问题，新版没上去构建这关迟早要过，别留到最后产物就绪dist/ 可以直接部署，错误早已修完本地先过构建关，上线才顺
1 / 4
Collect · 收齐源码和依赖
03 · 放进真实任务
什么时候会遇到它
部署的前置步骤
每次上线前都要先构建，产物才是部署的对象。
提前暴露错误
类型错误、漏装的依赖，构建阶段就报出来，不用等上线。
排查环境差异
「本地好好的，线上坏了」——先看两边构建产物是否一致。
04 · 想一想
用一个问题检查理解
本地 npm run dev 一切正常，一执行 npm run build 就报错。这说明什么？
查看答案
开发模式宽松、构建更严格：类型错误、只在本地装过的依赖，这时才现形。构建报错是在替你拦截一次线上事故——修掉再部署。
最容易踩的坑
「本地能跑」不等于「能构建」，「能构建」也不等于「线上正常」。部署前先在本地把 build 跑通。