从 Spring Initializr 下载下来的项目包里藏着一个几乎没人会多看一眼的application.properties。你信心满满地加上数据源、加上 Redis、加上 MyBatis然后启动。崩溃通常不会当场发生但等到报错出现时你会发现连该从哪一行改起都不知道。真正让你翻车的不是那些炫目的框架而是你默认按下的“合理”设置。这篇文章就挑五个从零搭建时最容易被忽略的配置点每一个都曾经让不止一个团队在深夜加班。编码问题你以为的“UTF-8”只是 IDE 的错觉很多人从 IDE 里直接运行项目一切正常可一旦打好 jar 包部署到 Linux 服务器程序中的中文注释变成乱码返回给前端的文案变成问号。编码问题从来不是小问题它只是在等待一个足够大的环境差异来引爆你。编码配置是所有配置的前提因为当你读不懂日志时其他一切都无从谈起。根本原因通常是 Maven 或 Gradle 构建时没有显式声明源代码编码平台默认编码在 CI 和本地未必一致。project.build.sourceEncoding这一行缺失足以让整个编译结果产生不确定性。再来看看配置文件本身。application.properties在 Spring Boot 2.4 之前默认用 ISO-8859-1 读取后来才改成了 UTF-8。如果你还停留在旧版本或者团队里有同事不小心把文件存成了 GBK那么spring.datasource.url里只要带个中文字符启动时就会给你报一个让你完全摸不着头脑的解析错误。与其指望所有工具默认一致不如从第一天就强制统一。把配置文件全部改成application.yml因为 YAML 格式原生支持 UTF-8同时设置 IDE 的文件编码并把构建工具的 encoding 属性写死。最好在启动脚本里也加上-Dfile.encodingUTF-8。这个问题常常被归类为“小问题”但它在从零搭建时最值得先做完。一个小处的不一致会在项目膨胀之后无限放大。例如日志文件里出现乱码ES 索引的字段值变成乱码再比如报表导出文件名变成一串问号。到了那时你再想回头统一编码牵涉的范围就不是一个文件了。所以第一次搭建就把它钉死。时区与日期LocalDateTime 的“幽灵时区”假设你存入数据库的时间是下午三点查出来却变成了晚上七点。别急着怀疑数据库先看看 JDBC 连接串里的serverTimezone到底写了什么。时区不是一次性配置它是横跨代码、数据库、系统环境的三方协议。多数教程让你写serverTimezoneUTC结果东八区的项目所有时间都少了八小时。正确的写法是serverTimezoneAsia/Shanghai或者用GMT%2B8。但这只是开胃菜更隐蔽的坑在 Jackson 序列化上。Spring Boot 默认用 Jackson 处理 JSON。当你返回LocalDateTime时如果不做任何配置得到的要么是2025-03-21T10:30:00这样的 ISO 字符串要么是一个更令人困惑的数组[2025,3,21,10,30,0]。默认的序列化器不是为人类设计的它只是为“不报错”设计的。在application.yml里设置spring.jackson.date-format看似有效但这条配置其实只对java.util.Date生效对 Java 8 时间类型完全无感。你需要通过Jackson2ObjectMapperBuilderCustomizer注册JavaTimeModule并且指定全局的日期格式。还有一个容易忽略的点LocalDate和LocalDateTime的格式应分开定义因为它们的序列化注解JsonFormat分别需要pattern和timezone。尤其是接收前端传来的时间字符串如果格式不匹配直接 400 报错。前端的时间字符串不会自己找到对应的时区你必须给它一个明确的契约。另外数据库连接串里的 JDBC 参数最好显式写在配置中心而不是依赖 JDBC 驱动的默认值。从零搭建时花十分钟处理时区和格式能让你在未来三年里避开无数个凌晨两点的工单。异步线程池Async 不是上了锁的保险箱很多人给方法加上Async就以为万事大吉结果高并发一来系统响应变慢、线程数飙升最后整台机器挂掉。Spring Boot 默认的线程池并不是为你无限量并发设计的它更像一个没有尽头的队列。TaskExecutionAutoConfiguration 提供的默认线程池核心线程数只有 8而队列容量和最大线程数都接近无限大。大流量到达时任务不会撑开线程池只会全部堆进队列直到内存被耗尽。默认配置在低并发下看起来非常完美但它掩盖了一个事实你完全不了解系统的真实容量。正确的做法是显式定义ThreadPoolTaskExecutor把核心线程、最大线程、队列容量、线程名前缀一次说清楚。线程池不是越大越好而是应该给每个任务一个明确的边界。更值得研究的是拒绝策略AbortPolicy会抛异常CallerRunsPolicy会让调用线程去执行任务后者在限流和保命上有奇效但却容易让人误以为“没被拒绝”。还有一个大多数人都没意识到的问题Async只有在调用方是代理对象时才会生效。如果你在同一个类里自调用比如this.doAsync()那么注解直接失效你的方法变成同步执行。自调用是 Spring 代理模式里最经典的陷阱而这个问题在异步配置下会被放大成性能事故。从零搭建时建议把异步方法单独放在一个 Service 里并且避免类内部互相调用。同时别忘了自定义AsyncUncaughtExceptionHandler否则异步任务里吞掉的异常你根本看不见。数据库连接池HikariCP 的“足够好”可能害了你HikariCP 是 Spring Boot 默认的连接池它的默认配置确实很优秀但优秀不代表适合你的场景。连接池默认参数是给通用应用兜底的而不是给你的慢查询兜底的。默认maximum-pool-size是 10如果你的服务有多个副本每个副本 10 个连接数据库连接数瞬间就会被占满。当一个接口出现耗时超过三秒的慢 SQL其他所有请求都会卡在获取连接上表现为“系统变慢”可你在日志里看到的只有一堆超时。排查这种问题最有力的配置是leak-detection-threshold。这个参数默认是 0即完全不检测连接泄漏把它设成5000毫秒一旦某段代码持有连接超过 5 秒HikariCP 就会在日志中打印出获取连接时的堆栈直接指向你泄漏的那个位置。如果没有这一行配置你只能在连接耗尽时靠猜来排查问题。另外connection-timeout、idle-timeout、max-lifetime这三个参数也常常被保持默认值但它们之间的配合直接决定了连接池在高负载下的行为。建议从零搭建时就根据压测结果固定一套参数而不是等事故再补。比如设置maximum-pool-size时最好使用((core_count 2) effective_spindle_count)这个经典公式作为起点然后再校正。还有一条容易被忽略的如果你在连接串中启用了useSSLfalse并且设置了allowMultiQueriestrue请务必确认这是业务需要的不要因为兼容而忽略了安全。数据库连接池的每次调优都应该是对流量模型的重新审视。十分钟的配置换来的是未来十年的安稳。Actuator健康检查端点可能是你的“告密者”Spring Boot Actuator 是生产环境必不可少的监控依赖但在从零搭建时很多人要么不加要么加了之后无脑暴露所有端点。在 Web 端暴露方面Spring Boot 默认只开放health端点但这并不意味着它绝对安全。因为health端点如果配置了show-detailsalways它会把数据库、Redis、消息队列的具体状态一并输出任何人都可以从响应里推断出你的技术栈和依赖版本。更严重的是如果你图省事用了management.endpoints.web.exposure.include那么/actuator/env、/actuator/configprops、/actuator/heapdump都会直接暴露给未授权用户。env端点会把你配置中的敏感信息暴露出来即使部分 key 被脱敏整个配置空间的细节也足以让攻击者设计出精准的攻击。heapdump则可以让你下载整个 JVM 堆的内存快照。暴露监控端点不是让你获得安全感而是把运维的钥匙交到了攻击者手里。从零搭建时请先把包含列表缩到最小health和info通常足够了。建议把 Actuator 的端口单独设置比如management.server.port9091并且只在内网开放同时启用management.endpoint.health.show-detailswhen-authorized。生产环境的便利通常都以安全的牺牲为代价。另外shutdown端点默认关闭这个开关千万别因为测试方便而打开。如果你用了 Spring Security不要忘记给 Actuator 路径配置独立的权限规则如果用了网关更要在这一层就拦截掉对 actuator 的访问。这些细节在搭建时看似多余却在每一次安全审计中成为关键。从零搭建一个 Spring Boot 项目并不难难的是把每一个容易被忽略的默认值都变成显式的、深思熟虑的选择。没有配置也是一种配置而且往往是最危险的配置。上面提到的五个方向并没有覆盖所有坑但它们代表了一种态度不要依赖任何框架为你代付的欠款。尽早把编码、时区、线程池、连接池和安全端点纳入你的项目模板下一次从零搭建时你就能把时间真正花在业务上而不是事故上。