部署
Deployment也常被叫作：上线发布放到服务器上
「在我电脑上是好的，怎么让别人打开网址也能看到？」
部署 Deployment
把本机做好的东西送到线上服务器并真正生效，让别人通过网址就能用。
部署是整条链路上最容易产生「假完成」的一步，因为它有太多个「看起来成功了」的中间状态：文件传上去了、构建成功了、进程重启了——但用户打开网址，看到的还是旧的。
原因通常是这几个：构建产物没被真正替换；进程还在跑旧代码；有一层缓存或 CDN 挡在前面；或者反向代理指向的目录根本不是你刚更新的那个。这些都不会报错，只会安静地让你以为上线了。
所以部署的唯一有效验证只有一条：用浏览器打开那个真实网址，看到新内容。 不是看部署日志，不是看进程状态，不是看 AI 说「已成功部署」。打开网址，用无痕窗口，看到新的东西。
还有比「上没上去」更重要的一件事：能不能退回去。 部署之前先确认回滚方式——旧版本还在不在、怎么切回、需要多久。没有回滚方案的部署不叫上线，叫赌博。改动越接近钱、数据和用户，这条越不能省。
长什么样 真实可交互，不是截图
「进程已重启」
「文件已上传」
知道旧版本在哪、怎么切回
出问题时看得见（日志/报错）
左边三条都是真的，也都可能同时成立而用户仍然看到旧页面。中间任何一个环节断了，症状都一样：网址没变化。
拆开看，里面有这几块
-
1
构建 Build
把源码编译成能运行的产物。构建失败是最好的失败——它当场就告诉你。
-
2
传输 Upload / Sync
把产物送到服务器。注意是不是真的覆盖了正在被使用的那个目录。
-
3
切换 Switch / Restart
让服务开始用新产物。静态站是换目录，服务端应用通常要重启进程。
-
4
缓存失效 Cache bust
浏览器缓存、CDN 缓存、反向代理缓存。任何一层没清，用户还看旧的。
-
5
验证 Verify
打开真实网址确认。这一步不能被任何日志替代。
-
6
回滚方案 Rollback
旧版本在哪、怎么切回、多久能完成。部署之前就要有答案。
常见的有哪几种
只有 HTML/CSS/JS，传上去就能用，风险最低，回滚就是换回旧目录。
用在：官网、文档、术语站这类内容型站点
需要构建 + 重启进程，有依赖和环境变量，失败面大得多。
用在：带登录、数据库、接口的应用
先让一小部分用户用新版本，观察没问题再全量。
用在：用户量大、改动有风险
准备两套环境，切流量而不是改文件，回滚就是切回去。
用在：要求零停机
容易搞混？这样区分
构建是把源码变成产物，在哪都能做；部署是把产物放到线上并生效。构建成功是部署的前提，绝不是部署完成。这两个词被混用，是「假上线」的头号原因。
托管是东西住在哪（服务器、平台、空间）；部署是把东西搬进去的那个动作。换托管商是搬家，部署是每次搬新家具。
部署是技术动作（新代码在线上跑起来了）；发版是产品动作（对用户宣布可用了）。成熟做法是先部署但用开关关着，确认没问题再打开——这两件事可以分开。
什么时候用得上
先只部署一个静态页面到目标路径，确认网址能打开，再往里放真东西。地基先验，别一次全押。
也要打开无痕窗口看一眼。缓存最喜欢在小改动上骗人。
先回滚，再排查。在线上边debug边让用户看着白屏，是最贵的调试方式。
你可以这样跟 AI 说
直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。
【任务】把 [项目/目录] 部署到 [目标地址，例如 example.com/xxx/] 【分两步，不要合并】 第一步：只做构建，把原始输出贴给我，等我确认 第二步：我说开始之后再部署 【部署前必须先回答我】 1. 会写入服务器上的哪个目录？会覆盖什么？ 2. 现在那个位置的旧内容是什么？备份放在哪？ 3. 如果部署后出问题，具体怎么退回去，大概多久？ 4. 需要重启什么进程吗？会影响线上其他服务吗？ 【边界】不要动其他目录；不要改配置文件里与本次无关的部分；不要重启与本次无关的服务；不要读取或输出任何密钥、环境变量和真实用户数据 【交付】部署完成后，告诉我用浏览器打开哪个网址、应该看到什么，并把服务器返回的状态码贴给我
「分两步，不要合并」这一句能救你很多次。构建和部署被合成一个动作时，构建里的警告会被顺手带上线；分开之后，你在最便宜的位置就拦住了问题。
它说「做好了」，你怎么自己验
这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「生产」这层：线上真实环境有效，有回滚和观测。
要亲眼看到这些，才算数
- 用无痕窗口打开真实网址（不是本地端口，不是预览地址），看到新内容。
- 换一台设备或手机流量再打开一次，排除本机缓存和 DNS 缓存。
- 确认旧版本备份在哪、回滚命令是什么——最好让他把回滚命令写出来给你看。
- 如果是带接口的应用：点一个真实会读写数据的操作，确认不只是页面变了。
- 看一眼错误日志或监控，确认没有新的报错刷屏。
- 部署没有顺手动到其他目录或服务（问一句「你这次一共改了服务器上哪几个位置」）。
它常这么糊弄你
- 「已成功部署」——但他只是执行了脚本，没有打开网址。要求贴出访问网址后的实际状态码和页面标题。
- 「构建通过就等于上线了」——这两件事之间还有传输、切换和缓存三道门。
- 本地端口截图冒充线上效果。看地址栏：
localhost和你的域名不是一回事。 - 为了让部署成功，顺手改了服务器上的配置或重启了别的服务，却没告诉你。
- 没有备份就覆盖。等你发现问题时，旧版本已经不存在了。
- 只在自己浏览器里刷新看到新内容——那可能是他刚清了缓存，用户没清。
这是全站唯一默认要求推到「生产」层的一类词条。理由很简单：部署是少数用户会先于你发现失败的动作。
考考你 选一个你觉得对的
AI 说「已成功部署到线上」。哪个验证方式最可靠？
B 和 C 都只能证明「动作发生了」，而部署失败的典型形态恰恰是「动作全部成功，用户看到的还是旧的」。D 是把验证交还给被验证的一方。只有 A 直接站在用户的位置上看结果，并且顺手补齐了最重要的退路。