你埋头写了一年代码，自以为对Spring Boot、JPA、Maven了如指掌，结果上线第一天就搞崩了生产环境。别笑，这种事每天都在发生。企业级Java开发从来不是“写完能跑”就行，那些藏在“理所当然”里的坑，往往比业务逻辑复杂一百倍。真正的生产级代码，不是能编译通过，而是能在各种异常边缘持续稳定运转。今天我们不聊理论，只聊那些让我和身边朋友赔过钱、加过班、背过锅的真实陷阱，以及经过血泪教训验证的最佳实践。

陷阱一：空指针是“设计问题”，不是“代码问题”

NullPointerException（NPE）几乎是每个Java开发者的老朋友了。但大多数人处理它的方式极其原始：在调用链上到处堆if (obj != null)。这种防御式编程不仅让代码变成“橡皮泥”——越补越丑，而且治标不治本。NPE的本质不是你没有判空，而是你允许了“null”在系统中自由传播。一个接口可能返回null，一个方法可能传入null，一个Map可能get不到key返回null——每多一个null来源，就多一个潜在的NPE。

最佳实践是使用Optional类来显式表达“可能缺失”的语义。比如从数据库查询一个用户，如果可能不存在，方法签名就应该是Optional<User> findById(Long id)而不是返回null。调用方必须通过orElse、orElseThrow等方式处理缺失情况，而不是靠默认值偷偷掩盖问题。另外，永远不要在实体类或DTO中给集合字段赋值为null，应该初始化为空集合（Collections.emptyList()或new ArrayList<>()），这样任何遍历和流式操作都不会报错。还有一条冷门但重要的原则：从外部系统（如RPC调用、消息队列）拿到的对象，必须立即做一次“null安全转换”，不要放任空值进入核心业务逻辑。

陷阱二：事务“传播”不是你想的那样分布式

Spring的@Transactional注解用起来很简单，但90%的开发者不知道它背后的传播行为会坑死人。最常见的情况是：在一个Service方法A上加了@Transactional，然后调用另一个Service方法B，B也加了@Transactional(propagation = Propagation.REQUIRES_NEW)。你以为B会开启一个新事务，独立提交？错。关键问题是：Spring默认的AOP代理只能拦截外部调用，同一个类的内部方法调用不会走代理，因此B上的@Transactional根本不会生效，事务边界直接被忽略。

更隐蔽的陷阱是事务中抛出RuntimeException导致回滚，但如果捕获了异常且不重新抛出，Spring无法知道需要回滚，于是脏数据被提交。最佳实践：在@Transactional方法中，如果一定要捕获异常，请务必显式调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，或者直接让异常抛出到外层由容器处理。

另一个痛点是长事务。传说有人在一个@Transactional方法里调用了远程HTTP服务，等待30秒HTTP超时，数据库连接一直被占用，最终连接池耗尽，整个应用宕机。永远不要在事务中执行IO操作（网络请求、文件写入、长时间计算）。事务应该只用于数据库的读写操作，且要尽量短。如果需要分布式事务一致性，请考虑使用消息队列或Saga模式，而不是用一个万能@Transactional撑起所有。

陷阱三：日志打印的“凶手”是你自己

搞出线上故障后，开发者最常说的就是“日志里没有错误信息”。但检查日志系统，发现每秒钟打印了上千条DEBUG级别的循环日志，把异常信息冲刷得无影无踪。日志不是越多越好，而是越“精准”越好。常见反模式：在for循环里打印日志，每次迭代都输出一条记录；打印异常时只打e.getMessage()而不打印全栈跟踪；日志级别不分场景，生产环境开着DEBUG或TRACE。

最佳实践明确：生产环境日志级别为WARN或ERROR，仅INFO用于记录核心业务节点（如订单创建成功、支付完成）。异常日志必须使用log.error("操作失败，参数：{}", param, e)这种写法，它会完整打印堆栈信息，而参数占位符{}由SLF4J内部优化，只有当日志级别满足时才会进行字符串拼接，不影响性能。另外，配置异步日志Appender（如Logback的AsyncAppender）至关重要，它可以让日志写入操作脱离业务线程，避免IO阻塞。

还有一条容易忽视的金句：禁止使用System.out.println或e.printStackTrace()输出日志。它们不会被日志框架管理，无法控制级别，也无法写入指定文件，甚至可能因为线程安全问题导致信息错乱。所有日志必须通过SLF4J门面输出，方便后续切换日志实现。

陷阱四：并发下的“隐形”数据竞争

企业级应用几乎都是多线程的，但大部分Java开发者对内存模型的理解停留在“加个synchronized就安全了”。实际上，最简单的HashMap在并发put时可能导致死循环（JDK1.7之前的rehash问题），但到现在仍有项目在使用HashMap作为缓存容器，甚至用SimpleDateFormat做全局的日期格式化——这两个类都不是线程安全的。

最佳实践：首先，识别所有需要共享的、可变的状态，并为它们选择正确的线程安全容器。HashMap换成ConcurrentHashMap，ArrayList换成CopyOnWriteArrayList或Collections.synchronizedList，SimpleDateFormat换成DateTimeFormatter（它是不可变且线程安全的）。其次，对于计数器、累加器等高频写操作，使用AtomicLong或LongAdder替代synchronized，性能可提升数倍。

但最隐蔽的陷阱是“复合操作”的原子性。比如检查缓存中是否有值，有则返回，没有则查询数据库并放入缓存——“检查-执行”两步并非原子，两个线程可能同时查到没有，然后都去查数据库，导致数据库压力翻倍。务必使用ConcurrentHashMap.computeIfAbsent或双重检查锁定+volatile来保证线程安全的懒加载。另外，关于volatile的误用：它只能保证可见性，不能保证原子性，count++这种操作必须用锁或原子类。

陷阱五：数据库查询的“隐形炸弹”

很多Java项目使用JPA或MyBatis，但开发者往往为了省事写出“无形”的慢查询。最常见的就是JPA的findAll操作，在数据量达到数十万时，它会把全表数据加载到内存，且开启一级缓存，导致堆内存暴涨。另一个经典反模式：在循环中逐条查询数据库，比如在for循环里反复调用findById，最终产生N+1次查询。

最佳实践：永远不要在循环中做单个查询。除非必要，否则所有批量操作应该使用IN查询、批量插入或Specification动态查询。对于JPA，使用@EntityGraph或@Query显式指定join fetch来解决N+1问题，而不是依赖懒加载在循环中触发。对于复杂统计，直接写原生SQL或使用MyBatis的XML映射，让DBA能直观审查SQL。

还有关于索引的陷阱：很多开发者以为加了@Column(unique = true)就能自动创建唯一索引，但JPA在DDL自动生成时确实会建，可生产环境往往由DBA手动维护，而@Index注解可能根本没被指定字段。最佳实践是强制所有查询字段（特别是WHERE、JOIN、ORDER BY涉及的字段）必须有对应的数据库索引，并且定期通过慢查询日志分析未命中索引的查询。

陷阱六：异常处理的“烂尾楼”

不少项目的异常处理逻辑堪称“灾难现场”：捕获Exception后直接吞掉不打印，返回空列表让前端显示空白；或者将业务异常与系统异常混为一谈，全部抛出RuntimeException，导致调用方无法区分是参数错误还是服务器崩溃。异常处理的核心原则：异常是用于处理非预期情况的，不要用异常控制业务流。

最佳实践是构建一个清晰的异常体系：自定义业务异常（如BusinessException）继承RuntimeException，并包含错误码和可读消息；系统异常（如数据库连接失败）单独封装，并打上@ResponseStatus或由全局异常处理器统一处理。绝对禁止捕获Throwable或Exception，这会让OutOfMemoryError这样的致命错误也被吞掉，应用会继续运行在亚健康状态，症状越来越严重。

另外，对于“预期可能失败”的调用（如远程RPC超时、第三方API返回错误），不要用异常来传递状态，而是使用返回码、Result对象或Optional。异常的开销很大——填充StackTrace并构建调用链会消耗大量CPU和内存，在高并发下会成为性能瓶颈。

陷阱七：配置文件里的“隐私漏洞”

企业级应用通常需要连接数据库、调用第三方API，这些配置信息往往直接写在application.properties或application.yml里，然后提交到Git仓库。无数安全事故因此发生：密码泄露、密钥曝光，甚至被爬虫扫描到公开仓库导致数据库被拖库。代码中的敏感信息永远不应该硬编码，更不能提交到版本控制。

最佳实践：使用配置中心（如Spring Cloud Config、Nacos、Apollo）统一管理配置，支持动态刷新；或者使用环境变量、Vault等密钥管理工具。即使本地开发，也应该使用.env文件并通过.gitignore排除。对于数据库密码等敏感字段，一定要加密存储，在应用启动时通过Jasypt或Spring Cloud的@Value+ 加密注解自动解密。

还有一点：框架的默认配置往往不安全。比如Spring Boot的Actuator在生产环境默认暴露所有端点，包括heapdump、threaddump、env，任何人都可以访问堆转储文件，直接读取内存中的明文密码。务必通过management.endpoints.web.exposure.exclude=关闭所有端点，只开放必要的健康检查。

陷阱八：性能优化“凭感觉”不如“靠数据”

很多开发者一提起性能优化就想到“用缓存”，然后给所有查询都套上@Cacheable。结果缓存命中率极低，反而增加了Redis的网络开销和内存占用。性能优化的第一原则：先测量，再优化。没有jstack、jmap、GC日志分析就动手改代码，十有八九会越改越糟。

最佳实践：在构建和测试阶段就集成Profiler（如Async Profiler、JProfiler），找出热点方法。生产环境必须启用-XX:+PrintGCDetails和-Xloggc:/path/gc.log，通过GC日志判断是否频繁Full GC导致STW。对于SQL慢查询，在MySQL层面开启slow_query_log，定期分析。只有基于数据，才能做出正确的优化决策，比如将数据库查询改为缓存，或调整连接池大小。

另外，注意Java的“假同步”：Vector、Hashtable已经基本不使用，但很多老旧代码还在用StringBuffer（同步的）而非StringBuilder（非同步的）。在方法内部局部拼接字符串时，用StringBuilder性能更好，因为不需要获取锁。

陷阱九：单元测试与“不靠谱的Mock”

企业级项目如果没有单元测试，那代码质量基本靠赌。但很多项目虽然有测试，却写成了“验证Mock框架是否正常工作”的代码。比如对Service层测试时，把所有依赖都Mock掉，然后只验证方法是否被调用，根本不关心真实逻辑。Mock不是让你偷懒的，而是让你隔离外部依赖，专注于测试业务逻辑的正确性。

最佳实践：单元测试应该覆盖核心的业务分支和边界条件。永远不要Mock你自己写的、没有外部IO的类（比如工具类、校验类），直接使用真实实例，否则你只是在测试Mock本身。对于数据库、RPC等外部依赖，使用@SpringBootTest或@DataJpaTest加内存数据库（如H2）进行集成测试，同时保证测试环境与生产环境的方言一致。测试必须可重复、无副作用，最好在每个测试方法执行后清理数据（@Transactional回滚或@BeforeEach清理）。

还有一条容易被忽略的点：不要在测试中依赖特定顺序执行。JUnit不保证测试方法的执行顺序，如果测试之间共享了静态变量或数据库状态，结果会随机失败。确保每个测试方法独立且隔离。

陷阱十：依赖管理的“依赖地狱”

Maven或Gradle的依赖冲突是企业级Java项目的顽疾。比如项目里同时引入了不同版本的Jackson，ClassLoader会加载其中一个，而另一个版本的类被隐藏，导致NoSuchMethodError或ClassNotFoundException。很多人选择了暴力做法：在pom.xml里到处exclude，最终版本一团混乱。

最佳实践：使用Maven的dependency:tree或Gradle的dependencies任务查看完整树，并通过dependencyManagement（Maven）或constraints（Gradle）强制统一版本。对于像日志框架这种常见冲突（比如Spring Boot自带logback但其他库引用log4j），使用spring-boot-starter-logging并全局排除冲突包。另外，一定要定期检查并升级依赖版本，不只要关注功能更新，更要关注安全漏洞（CVE）修复。使用OWASP Dependency-Check或 Snyk 等工具自动扫描。

禁止使用SNAPSHOT版本作为正式依赖，除非你100%确定其稳定性，并且愿意承担随时被破坏的风险。所有第三方库应该锁定到具体的Release版本，避免构建时下载到不同的SNAPSHOT导致不可复现。

总结：从“能跑”到“跑得稳”

企业级Java开发不是写几个Controller和Service就能交付的，它关乎工程纪律、系统韧性和团队协作。每一个陷阱的背后，都是对“思维定势”的挑战——你以为的空指针、你以为的事务、你以为的Mock，往往就是线上事故的导火索。

真正的高手，不是不会犯错，而是能把常见的错误模式提炼成“检查清单”和“代码审查的杀手锏”。当你把“生产环境无小事”刻进每一行代码里，你便不再只是“写代码的人”，而是系统的守护者。从今天开始，审视自己的项目，逐一排查这些陷阱，让代码从“能跑”真正进化到“跑得稳”。