企业官网建设流程全解析

去年团队上线了一个新开发的订单服务，所有测试环境跑得风生水起，部署到生产环境刚启动就疯狂报错。回滚、排查、修复，折腾了两个小时才发现问题出在一个不起眼的配置上：spring.datasource.hikari.maximum-pool-size用的是默认值 10，而生产环境的数据库连接池上限是 5。服务一启动就把连接占满了，其他依赖同一个数据库的服务集体超时。那个加班的晚上，运维同事盯着监控图上一路飙升的失败率，幽幽地说了一句：“要是上线前有人检查一下连接池配置就好了。”

部署前的配置检查，不是为了走流程，是为了把那些“本地没毛病”的错觉扼杀在摇篮里。以下这几项检查，是我在过去几年踩过的坑里捞出来的，建议你在每次部署前逐条过一遍。

连接池和线程池：别让默认值害了你

这是最容易被忽略但出事最要命的一类配置。HikariCP 默认maximumPoolSize是 10，Tomcat 的max-threads默认是 200。这些默认值在本地开发时绰绰有余，但到了生产环境，流量一上来就可能成为瓶颈或灾难。

检查清单第一条：确认连接池的最大值不超过数据库服务端的连接数上限，预留至少 20% 的余量给其他服务。同时检查connection-timeout和idle-timeout是否设置了合理的超时时间，防止慢 SQL 把连接占死。线程池方面，server.tomcat.threads.max要根据服务器的 CPU 核数和业务 I/O 占比来调，既不能让线程数过多导致上下文切换开销，也不能太少导致请求排队。这不是能蒙出来的数字，压测报告上那一行最优并发数，就是你要填进去的值。

日志级别和滚动策略：别让磁盘写爆了

很多项目在测试环境大开logging.level.root=debug方便排查问题，然后这个配置原封不动地被带到了生产环境。生产环境里每一行 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.password=123456，而脚本又被不小心提交到了代码仓库。密码明文躺在 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，每次部署前花十分钟逐条过一遍。你会发现，大多数夜里被叫醒的情况，其实都可以在白天用一个勾号避免。