prod怎么用？三种发布方式实测
prod怎么用，重点不是记住一条部署命令，而是选对发布路径并控制变更风险。我按同一个Web服务的实际操作流程，对比手动部署、Docker流水线和托管平台三种方式，从上手速度、配置管理、回滚和排障四个方面拆开讲，方便不同规模的项目直接选。
上手速度：手动最快，托管平台最省步骤
同一个Node.js接口首次放进prod，手动方式需要准备服务器、运行时、反向代理和进程守护；Docker方式还要写镜像文件与流水线；托管平台通常连接代码仓库、填写构建命令和环境变量即可。只看第一次上线，托管平台步骤最少，手动部署也不算慢。
但第二次发布差距就出来了。手动方式容易遗漏依赖安装或服务重启，Docker可用同一镜像重复部署，托管平台则会自动构建。短期试水可以手动，持续迭代的项目更适合可重复执行的后两种方式。
配置管理：环境变量胜过改文件
三种方式都不要把prod密码写进仓库。手动部署可使用权限受限的环境文件，并确保它不进入Git；Docker应在启动容器时注入变量，不要用ENV把密钥烘进镜像；托管平台则用它自带的Secret功能，修改记录通常更清楚。
实际检查时，我会在启动阶段验证必填变量，缺少DATABASE_URL就直接失败，而不是等用户请求进来才报错。还要区分普通配置与秘密：日志级别可以进配置文件，数据库密码和签名密钥必须进入受控密钥存储。
回滚能力：镜像版本最直观
手动覆盖代码最难回滚，因为服务器目录可能混有旧文件和临时修改。至少要保存带提交号的发布包，并让软链接切换版本。Docker可以为镜像标记Git提交哈希，异常时重新启动上一镜像；托管平台一般提供历史部署列表，点选旧版本即可回退。
无论选哪种方式，数据库迁移都不能被忽略。先做兼容旧代码的加字段，再发布应用，最后清理旧字段。直接重命名或删除列，会让应用回滚后无法读取数据，界面上那个“Rollback”按钮也救不了场。
排障体验：控制权与维护量互换
手动服务器能查看完整系统日志和网络状态，控制最细，但补丁、磁盘和进程都要自己管。Docker让运行环境更统一，排查时要熟悉容器日志、健康检查和端口映射。托管平台维护量最低，不过底层指标和网络权限可能受套餐限制。
我的选择标准很朴素：个人工具优先托管平台；需要固定依赖和稳定流水线时用Docker；只有必须控制操作系统或特殊网络时才手动维护服务器。prod怎么用没有唯一命令，正确答案是部署可重复、状态可观察、故障可回退。
常见问题
代码怎么从dev发布到prod？
通过代码评审和自动测试后构建一次制品，先部署到staging验证，再将同一制品灰度发布到prod，观察指标后全量。
prod环境变量放在哪里？
优先放云平台Secret、密钥管理服务或CI/CD受保护变量中。不要提交到Git，也不要打印到构建日志。
发布prod后要观察多久？
至少覆盖一轮核心请求和常见异步任务。高流量服务可先观察10至30分钟，低频业务应延长窗口，不能只看部署状态为成功。