去年团队上线了一个新开发的订单服务所有测试环境跑得风生水起部署到生产环境刚启动就疯狂报错。回滚、排查、修复折腾了两个小时才发现问题出在一个不起眼的配置上spring.datasource.hikari.maximum-pool-size用的是默认值 10而生产环境的数据库连接池上限是 5。服务一启动就把连接占满了其他依赖同一个数据库的服务集体超时。那个加班的晚上运维同事盯着监控图上一路飙升的失败率幽幽地说了一句“要是上线前有人检查一下连接池配置就好了。”部署前的配置检查不是为了走流程是为了把那些“本地没毛病”的错觉扼杀在摇篮里。以下这几项检查是我在过去几年踩过的坑里捞出来的建议你在每次部署前逐条过一遍。连接池和线程池别让默认值害了你这是最容易被忽略但出事最要命的一类配置。HikariCP 默认maximumPoolSize是 10Tomcat 的max-threads默认是 200。这些默认值在本地开发时绰绰有余但到了生产环境流量一上来就可能成为瓶颈或灾难。检查清单第一条确认连接池的最大值不超过数据库服务端的连接数上限预留至少 20% 的余量给其他服务。同时检查connection-timeout和idle-timeout是否设置了合理的超时时间防止慢 SQL 把连接占死。线程池方面server.tomcat.threads.max要根据服务器的 CPU 核数和业务 I/O 占比来调既不能让线程数过多导致上下文切换开销也不能太少导致请求排队。这不是能蒙出来的数字压测报告上那一行最优并发数就是你要填进去的值。日志级别和滚动策略别让磁盘写爆了很多项目在测试环境大开logging.level.rootdebug方便排查问题然后这个配置原封不动地被带到了生产环境。生产环境里每一行 DEBUG 日志都在消耗磁盘 I/O如果流量稍微大一点一天写满几十个 GB 是常事。上线前强制做三件事将 root 日志级别设为 WARN 或 INFO确认logback-spring.xml里配置了按大小和日期滚动的策略检查日志保留天数通常生产环境保留 7 到 15 天足矣。还要多留一个心眼日志框架的版本是否与 Spring Boot 版本兼容。曾见过一个项目因为 logback 版本过旧不支持配置中心的动态刷新结果改了日志级别却不生效排查问题时满屏无用信息。健康检查和监控端点确保出了问题能看见Spring Boot Actuator 是运维的双眼但如果部署前没有配置好暴露规则这双眼睛就等于蒙上了眼罩。关键检查项management.endpoints.web.exposure.include不要写按需暴露health、metrics、info即可management.endpoint.health.show-details在生产环境建议设为never或when-authorized避免暴露数据库连接状态等敏感信息为 Actuator 端点配置独立的端口或路径前缀防止和业务接口混在一起被流量打到。同时检查自定义的HealthIndicator是否确实反映了依赖组件的真实状态。比如 Redis 连接断了但你的健康检查只看数据库那监控系统就不会报警等用户反馈了才知道出事了。环境变量和敏感配置别把密码留在命令行里这是老生常谈但每季度至少出一次事故。有人为了方便在启动脚本里写了java -jar app.jar --spring.datasource.password123456而脚本又被不小心提交到了代码仓库。密码明文躺在 Git 历史里删都删不干净。部署前自查生产环境所有敏感配置必须通过环境变量或配置中心注入application-prod.yml 里只保留占位符${DB_PASSWORD}。同时检查是否使用了Value注入敏感字段并确认这些字段在日志中不会被无意打印。另外不要忽略spring.cloud.bootstrap.location这类配置——它在应用上下文刷新前就加载了如果这里引用了敏感信息同样需要走环境变量通道。元数据配置服务名和端口别打架微服务架构下spring.application.name决定服务在注册中心的名字server.port决定它监听哪个端口。这两条配置如果写错了服务之间互相找不到是家常便饭。部署前核对在目标环境的配置文件中确认服务名和端口是否正确检查eureka.instance.instance-id或spring.cloud.nacos.discovery.service是否包含 IP 和端口信息确保多实例部署时注册中心不会覆盖如果用了随机端口确认注册中心能正确拿到映射后的端口。更深一层检查spring.cloud.config.uri或spring.cloud.nacos.config.server-addr是否指向了正确的配置中心地址避免测试环境的服务跑到生产环境的配置中心去拉配置造成数据串写。启动前自测模拟一条请求跑通全链路所有配置检查完毕之后最后一个动作不是直接点“部署”而是在预发布环境模拟一条完整的业务请求从网关到服务再到数据库和缓存一路看到底能不能通。这个动作的核心不是测业务逻辑而是测配置在真实环境下的联合生效情况。尤其要关注日志里有没有输出不该有的敏感信息链路追踪的 traceId 是否传递完整熔断器和限流器的阈值是否生效定时任务的 cron 表达式是否在正确的时区执行。部署不是终点配置检查是那个让终点不变成事故现场的缓冲垫。把这些检查项做成一个 checklist每次部署前花十分钟逐条过一遍。你会发现大多数夜里被叫醒的情况其实都可以在白天用一个勾号避免。