一、审计阶段拿到代码第一件事不是部署是审① 目录结构扫描先不跑代码先看目录。一个项目的目录结构能直接反映架构水平。核心判断标准业务逻辑是否和框架代码分离。如果控制器里嵌着数据库连接、模板里写着业务判断这个项目后续改造成本会非常高。② 依赖清单核对把 composer.json 或 package.json 拉出来逐项核对版本号和许可证。踩过的坑有一次部署到一半发现一个关键依赖库的版本和PHP环境不兼容回退重装浪费了大半天。从那之后依赖核对放在第一步。③ 硬编码扫描全项目搜索 IP 地址、域名、绝对路径、密钥。这些东西绝对不能硬编码在代码里。找到了全部抽到环境变量。核心原则代码和环境分离。同一份代码换个环境改配置就能跑不用改代码。二、环境搭建和审计同步进行审计和搭环境可以并行。运行环境选型技术栈选型上我倾向用经过大规模生产验证的成熟方案。不做第一个吃螃蟹的人。核心原则选最稳的不选最新的。生产环境不是实验场。环境隔离开发环境、测试环境、生产环境三套完全独立。数据库不能共用配置文件不能复用连服务器账号都分开。踩过的坑早期图省事测试环境和生产环境共用一台服务器。有次测试时一个死循环把CPU打满生产环境跟着挂了。三、配置检查最容易出事的环节代码没问题环境没问题一跑就报错——十有八九是配置。检查清单检查项常见问题数据库连接字符集不一致导致乱码缓存配置未设密码或使用默认端口文件权限上传目录不可写定时任务路径硬编码换环境失效日志路径目录不存在报错日志也丢了第三方密钥测试环境密钥混入生产每一项都要手动验证一遍。自动化脚本能查语法查不了逻辑。四、数据迁移最容易被低估的一步结构迁移 vs 数据迁移结构迁移用迁移工具问题不大。真正麻烦的是数据迁移。踩过的坑旧系统用户ID是自增数字新系统用户ID是UUID。直接导入后所有关联表全乱。最后写了一个映射脚本跑了两天才对齐。迁移原则先迁结构再迁数据先迁基础数据再迁业务数据每迁一张表验证一张表保留原始备份至少保留七天核心原则宁可慢不能错。数据一旦污染修复成本是指数级的。五、安全加固上线前的最后一道防线服务端加固关闭不必要的端口和服务数据库不对外开放端口SSH 禁用密码登录只用密钥设置访问频率限制开启 HTTPS证书自动续期应用层加固SQL 注入防护XSS 过滤文件上传类型白名单接口鉴权全覆盖敏感数据加密存储核心原则安全不做加法做减法。只开放必须开放的其他全关掉。六、灰度上线不要一把梭灰度策略先切 10% 流量观察半小时。日志正常、错误率无波动、响应时间无异常——扩到 50%。再观察一小时一切正常——全量切。踩过的坑有次觉得改动不大直接全量上线。一个配置文件忘改全站报错三分钟。从那之后再小的改动也走灰度。回滚预案每次上线前准备好回滚方案。不是大概知道怎么回滚是写好回滚脚本、验证过、放在手边。核心原则上线不赌灰度验证出事不怕一键回滚。最后这篇文章写的不是理论框架是我实际帮人部署项目跑出来的经验。从审计到上线六个环节每一步都有坑。我踩过的你不用再踩一遍。如果你也在做项目部署或者在选型阶段需要判断一套方案部署成本高不高——这些经验应该能帮你少走弯路。个人技术经验分享具体操作请结合项目实际情况评估