企业官网建设流程全解析

1. 从“能跑就行”到“跑得明白”：Java 过渡阶段的核心分水岭

写这个系列写到第四篇，后台收到最多的一类留言是：“语法我都懂，跟着视频敲也能跑，但一合上教程就不知道从哪下手。”这个问题我太熟了，因为我自己当年就是从那个阶段熬过来的。Java 的过渡期，本质上不是“再学几个新语法”，而是从面向过程的模仿式编程切换到面向对象的建模式编程。这个切换点，才是真正拉开差距的地方。

这篇内容面向的是已经能写出for循环、能定义class、能调用方法，但面对一个完整需求时脑子里没有“结构感”的人。我会把过渡期最容易卡住的几个硬骨头拆开讲：面向对象到底怎么落地、集合与泛型怎么选、异常和并发怎么不踩坑、JVM 和工具链怎么建立直觉。每一块我都会给出“为什么这么设计”的解释，而不是只丢一段能跑的代码。因为过渡期最缺的不是代码量，是判断力——知道什么场景该用什么工具，知道一个写法背后在牺牲什么、换取什么。

我个人的经验是，过渡期大概会持续三到六个月，取决于你是否有意识地去“复盘自己的代码”。如果你只是不停地写新功能，写三年也还是那个水平；如果你每写完一个模块都回头问自己“这个类为什么这么拆”“这个集合为什么选它”，三个月就能有明显质变。下面这些内容，就是我这几年带人、自己踩坑、反复验证后沉淀下来的东西。

2. 面向对象不是背概念：把“类”当成职责的容器

2.1 为什么很多人写了三年还是面向过程

我见过太多这样的代码：一个UserService类里塞了两千行，注册、登录、改密码、发通知、算积分全在里面，方法之间靠一堆成员变量传递状态。这种代码能跑，但它不是面向对象，它只是把面向过程的代码装进了一个 class 的壳子里。判断标准很简单：如果你的类去掉class关键字、把方法都改成静态的，逻辑几乎不用改就能跑，那它就不是面向对象。

面向对象的核心不是“有类和对象”，而是职责的分配。一个类应该只对一件事负责，它的方法应该是它自己状态的自然延伸。举个我常用来解释的例子：Order（订单）这个类，它的职责是维护订单自身的状态——商品明细、金额、状态流转。至于“下单后发短信”，那是NotificationService的事；“下单后扣库存”，那是InventoryService的事。Order不应该知道短信怎么发、库存怎么扣，它只负责在自己状态变化时，通过事件或返回值告诉外界“我变了”。

这个思路落到实操上，就是先画职责边界，再写类。我现在的习惯是，拿到一个需求，先在纸上列出所有名词（候选类）和动词（候选方法），然后问自己：这个动词是哪个名词的“本能行为”？比如“计算订单总价”，总价是订单的属性，计算是订单的本能，所以放Order里；“发送订单确认邮件”，邮件不是订单的属性，发送也不是订单的本能，所以拆出去。这个“本能判断法”帮我省掉了大量后期重构的时间。

2.2 封装、继承、多态在真实项目里长什么样

教科书上讲封装就是“private + getter/setter”，这其实是个误导。真正的封装是隐藏实现细节，暴露稳定契约。我举个实际场景：一个PaymentGateway接口，定义了pay(amount)和refund(txId)两个方法。至于底层是走哪个渠道、怎么签名、怎么重试，调用方完全不需要知道。这样当渠道方改了接口协议，我只需要改实现类，所有调用方一行都不用动。这才是封装的价值——把变化关在盒子里。

继承这个东西，我现在用得越来越谨慎。因为继承是最强的耦合，子类和父类绑死，父类改一个方法签名，所有子类都得跟着改。我现在的原则是：优先用组合，只有在“is-a”关系非常明确、且父类设计时就考虑了扩展（比如模板方法模式）时才用继承。举个反例：很多人喜欢写一个BaseService，让所有 Service 都继承它，结果BaseService里塞了一堆通用方法，子类被迫继承了一堆用不上的东西。这就是典型的继承滥用。更好的做法是把通用逻辑抽成一个Helper或Util，谁需要谁注入。

多态是过渡期最容易被低估的东西。它的本质是用统一接口处理不同实现。我举个真实例子：一个报表导出功能，要支持 Excel、PDF、CSV 三种格式。如果不用多态，代码里会有一堆if (type == EXCEL) {...} else if (type == PDF) {...}，每加一种格式就要改这个 if。用多态的话，定义一个Exporter接口，三个实现类各自实现export()，调用方只依赖接口，新增格式只需要加一个实现类，调用方零改动。这就是开闭原则的落地——对扩展开放，对修改关闭。

2.3 一个可复现的职责拆分实操

我拿一个“列车调度”的小场景来演示（这个词在热搜里出现过，我猜很多人做课程设计会碰到）。需求是：有一组列车，每列有车次、始发站、终点站、发车时间；系统要能按发车时间排序、能查询某站的所有列车、能检测时间冲突。

新手常见的写法是写一个TrainManager，里面塞一个List<Train>，然后所有方法都写在这个 Manager 里。这个写法能跑，但职责全糊在一起了。我的拆法是：

• Train：只负责自身数据，提供getDepartureTime()等访问方法，实现Comparable用于排序。
• TrainRepository：负责列车的存储和检索，对外提供findByStation()、findAllSortedByTime()。
• ConflictDetector：只负责冲突检测逻辑，输入一组列车，输出冲突对。
• TrainScheduleService：编排层，组合上面三者完成业务用例。

这样拆的好处是：排序逻辑改了只动Train，存储换成数据库只动TrainRepository，冲突规则改了只动ConflictDetector。每个类都能单独写单元测试，不用启动整个系统。我实测下来，这种拆法在后期加需求时，改动量能比“大 Manager”写法少一半以上。

注意：职责拆分不是越细越好。我见过有人把每个方法都拆成一个类，结果类爆炸，读代码要跳十几个文件。判断标准是“这个类是否有独立的变更理由”，如果一个类里的两个方法总是同时因为同一个需求而修改，那它们就该待在一起。

3. 集合与泛型：选错容器，性能差十倍

3.1 ArrayList、LinkedList、HashMap 的真实取舍

面试八股文里背“ArrayList 查快增删慢，LinkedList 增删快查慢”，但真实项目里怎么选？我的经验是：90% 的场景直接用 ArrayList。原因很简单，LinkedList 的“增删快”只在“已经持有目标节点引用”的前提下成立，而实际业务里你几乎总是先查找再删除，查找本身就是 O(n)，LinkedList 的优势根本发挥不出来。而且 LinkedList 每个节点额外维护前后指针，内存开销比 ArrayList 大得多，CPU 缓存命中率也差。

HashMap 是过渡期必须吃透的。它的核心是用空间换时间，通过哈希函数把 key 映射到桶数组的某个位置，理想情况下查找是 O(1)。但有两个坑必须知道：第一，key 必须正确实现 hashCode 和 equals，否则会出现“明明放进去了却查不到”的诡异问题。我踩过一次，用自定义对象做 key，只重写了 equals 没重写 hashCode，结果两个逻辑相等的对象被当成不同的 key，Map 里出现了重复项。第二，HashMap 不是线程安全的，多线程并发 put 在扩容时可能形成环形链表导致 CPU 飙满，这个在 JDK 8 之后虽然改进了，但并发场景还是应该用ConcurrentHashMap。

我整理了一张选型对照表，这是我实际项目里总结的：

3.2 泛型擦除带来的那些“坑”

泛型是过渡期另一个容易翻车的地方。核心要记住一句话：Java 泛型是编译期的，运行期会被擦除。这意味着List<String>和List<Integer>在运行时都是List，你没法在运行时判断一个 List 的泛型参数是什么。这个特性带来几个实际影响。

第一，不能new T()，因为运行期 T 被擦除了，编译器不知道要创建什么类型。解决办法是传入Class<T>对象，用反射创建。第二，不能创建泛型数组，new T[10]编译不过，因为数组是协变的、运行期需要知道元素类型。第三，静态方法不能用类的泛型参数，因为静态方法属于类而非实例，而泛型参数是实例级别的。

我举个实际踩坑的例子：写一个通用的Result<T>包装类，序列化后反序列化时，T的类型信息丢了，反序列化出来是LinkedHashMap而不是原来的对象。解决办法是用TypeReference或者传入Class<T>。这个坑我在对接外部 API 时踩过，排查了半天才发现是泛型擦除导致的。

3.3 用泛型写出可复用的工具方法

泛型最大的价值是类型安全 + 代码复用。我举个自己常用的例子：一个分页工具方法。

public static <T> List<T> paginate(List<T> source, int page, int size) { if (source == null || source.isEmpty()) { return Collections.emptyList(); } int from = Math.min((page - 1) * size, source.size()); int to = Math.min(from + size, source.size()); return source.subList(from, to); }

这个方法对任何类型的 List 都适用，而且编译期就能保证返回类型和输入类型一致。如果不用泛型，要么用Object然后到处强转（运行期可能 ClassCastException），要么为每种类型写一个重载（代码爆炸）。泛型在这里的价值就是把类型检查从运行期提前到编译期，让错误在写代码时就暴露，而不是上线后炸。

实操心得：泛型方法声明里的<T>要放在返回类型之前，这是语法规定。另外，如果方法参数里出现了 T，编译器通常能自动推断类型，调用时不用显式指定。我见过有人每次都写Util.<String>paginate(...)，其实完全没必要。

4. 异常与并发：过渡期最容易埋雷的两块

4.1 异常不是用来控制流程的

新手最常见的异常误用是用异常做流程控制。比如查用户，查不到就抛异常，然后上层 catch 住当“没找到”处理。这个写法的问题在于：异常的创建和抛出是有成本的（要填充栈轨迹），在高频调用路径上会严重拖慢性能。更重要的是，它让代码的意图变得模糊——异常应该表示“意外情况”，而不是“预期内的分支”。

我的原则是：预期内的分支用返回值，预期外的错误用异常。查用户查不到，这是预期内的，返回Optional<User>或null；数据库连不上，这是预期外的，抛异常。这个界限划清楚，代码的可读性和性能都会好很多。

另一个坑是吞异常。我见过太多这样的代码：

try { doSomething(); } catch (Exception e) { // 什么都不做 }

这是最危险的写法，因为出了问题你完全不知道。正确的做法至少是记录日志，最好是要么处理，要么往上抛，要么包装成业务异常再抛。我现在的习惯是，catch 块里如果什么都不做，那必须写注释说明为什么可以忽略，否则一律记日志。

4.2 线程安全：从“知道”到“会用”

并发这块，过渡期的人通常知道synchronized，但不知道怎么选。我整理了一个决策路径：如果只是保护一个简单的计数器，用AtomicInteger；如果是保护一段复合逻辑，用synchronized或ReentrantLock；如果是读多写少的共享数据，用ReadWriteLock或volatile（注意 volatile 只保证可见性不保证原子性）。

ConcurrentHashMap是我在项目里用得最多的并发容器。它的computeIfAbsent方法特别适合做本地缓存：

Map<String, User> cache = new ConcurrentHashMap<>(); User user = cache.computeIfAbsent(userId, id -> loadFromDb(id));

这个写法是原子的，多个线程同时查同一个 key，只有一个会真正执行loadFromDb，其他线程会等待结果。这比“先 get 再 put”的写法安全得多，后者在并发下可能重复加载。

关于 AQS（AbstractQueuedSynchronizer），很多人背八股文背得很熟，但不知道它到底解决什么问题。简单说，AQS 是一个同步器的骨架，它把“排队、阻塞、唤醒”这套逻辑抽象出来，让ReentrantLock、Semaphore、CountDownLatch这些工具只需要实现“什么时候能获取锁、什么时候释放锁”的判断逻辑。理解 AQS 的价值在于，你能看懂这些并发工具的源码，知道它们的性能特征和适用边界，而不是只会调 API。

4.3 数据一致性：过渡期就该建立的意识

“Java 怎么保证数据一致性”这个热搜词说明很多人已经意识到这个问题了。我的经验是，一致性分几个层次：单机单线程靠事务，单机多线程靠锁和原子类，分布式靠分布式事务或最终一致性方案。

过渡期最该掌握的是单机多线程下的一致性。举个典型场景：一个库存扣减，多个线程同时扣，如果写成if (stock > 0) stock--;，在并发下会超卖。因为“判断”和“扣减”不是原子的，两个线程可能都通过了判断。解决办法是用synchronized包住，或者用AtomicInteger的decrementAndGet配合 CAS 循环。我实测过，用synchronized在低并发下性能足够，高并发下AtomicInteger的 CAS 更优，但要注意 CAS 在竞争激烈时会自旋消耗 CPU。

注意：不要过早优化并发。我见过有人在单线程场景下用ConcurrentHashMap，理由是“以后可能并发”。这是过度设计，增加了复杂度却没带来收益。先保证正确，再在压测中发现瓶颈后优化。

5. 工具链与 JVM：建立“代码之外”的直觉

5.1 环境变量配置与版本管理

“java 环境变量配置”是热搜常客，说明这是很多人的第一道坎。我简单说清楚原理：JAVA_HOME指向 JDK 安装目录，PATH里加上%JAVA_HOME%\bin（Windows）或$JAVA_HOME/bin（Linux/Mac），这样命令行才能找到java和javac。CLASSPATH现在基本不用手动配了，默认就是当前目录。

但我要提醒一个坑：多版本共存时的切换。我机器上同时装了 JDK 8、11、17，如果JAVA_HOME指向 8 但PATH里有个 17 的路径在前面，就会出现“java -version显示 17，但编译报错说源发行版 17 需要目标发行版 17”这种诡异问题。解决办法是确保PATH里只有一个 JDK 的 bin 目录，切换版本时改JAVA_HOME并重新打开终端。这个坑我在热搜里看到有人问，其实就是版本没对齐。

5.2 从“能跑”到“跑得好”：JVM 基础直觉

过渡期不需要深入 JVM 调优，但要有几个基本直觉。第一，堆内存分新生代和老年代，新创建的对象在新生代，经过多次 GC 还活着的才晋升到老年代。第二，Minor GC 频繁但快，Full GC 慢且会停顿，如果发现 Full GC 频繁，通常是内存泄漏或大对象过多。第三，栈是线程私有的，堆是共享的，所以局部变量天然线程安全，成员变量不一定。

我举个实际排查的例子：有次线上服务每隔几分钟卡顿一下，日志显示 Full GC。用jstat -gc一看，老年代几乎满了，但新生代很空。后来发现是一个静态 Map 一直在 put 从不清理，导致对象不断晋升到老年代。解决办法是换成带过期策略的缓存。这个排查过程用到的工具就是 JDK 自带的jstat和jmap，不需要额外装东西。

5.3 构建工具与依赖管理

Maven 和 Gradle 是过渡期必须会的。Maven 的核心是约定优于配置：标准目录结构、生命周期、依赖坐标。我建议新手先把 Maven 的pom.xml吃透，理解groupId、artifactId、version三坐标，理解scope（compile、test、provided、runtime）的区别。provided这个 scope 特别容易搞错，比如 Servlet API 在 Tomcat 里已经有了，打包时就不该带进去，否则会冲突。

依赖冲突是另一个高频坑。Maven 的依赖调解规则是“最短路径优先，路径相同先声明优先”。我遇到过 A 依赖 B 的 1.0，C 依赖 B 的 2.0，结果实际用的是 1.0，导致 C 的功能异常。排查工具是mvn dependency:tree，能看到完整的依赖树，找出冲突来源后用<exclusions>排除掉不需要的版本。

6. 常见问题与排查技巧实录

6.1 过渡期高频问题速查表

6.2 我踩过的三个典型坑

第一个坑是字符串拼接。早期我写循环拼接用+，数据量一大就慢得离谱。后来才知道每次+都会创建新的 String 对象，循环一万次就创建一万个对象。正确做法是用StringBuilder，它在内部维护一个可变字符数组，拼接是 O(1) 的。但要注意StringBuilder不是线程安全的，多线程下用StringBuffer。

第二个坑是对象深度拷贝。有次我改了一个对象的属性，结果发现另一个“不相关”的对象也变了，排查半天发现两个引用指向同一个对象。浅拷贝只复制引用，深拷贝才复制对象本身。实现深拷贝可以用序列化反序列化，或者手动递归复制。我现在的习惯是，如果一个对象要跨层传递且可能被修改，就在边界处做一次深拷贝，避免意外的共享状态。

第三个坑是动态代理的 self-invocation。用 Spring 的@Transactional时，如果在一个方法内部直接调用同一个类的另一个@Transactional方法，事务不会生效。因为 Spring 的事务是基于代理的，内部调用不走代理。解决办法是注入自己或者用AopContext.currentProxy()。这个坑我在做支付相关功能时踩过，排查了很久才定位到。

6.3 独家避坑建议

我的第一条建议是：写代码前先想清楚数据流。输入是什么、经过哪些处理、输出是什么、中间状态存在哪里。这个想清楚了，代码结构自然就出来了。我见过太多人上来就写，写到一半发现数据结构不对，推倒重来。

第二条建议是：每个类都问自己“如果需求变了，我要改几个地方”。如果答案是“很多地方”，说明职责没拆好。好的设计是，一个需求变更只影响一个类或一个方法。

第三条建议是：不要怕重构。过渡期最大的进步往往来自“把之前写的烂代码重写一遍”。我自己的习惯是，每完成一个模块，隔一天再回来看，如果觉得“这写的什么玩意”，那就说明有进步，然后动手重构。这个过程比写新代码学到的更多。

最后分享一个我常用的调试技巧：当遇到诡异问题时，先缩小范围。把可疑代码单独抽出来写一个最小复现，往往在抽的过程中就发现问题了。这个方法帮我解决过无数次“明明逻辑对但结果不对”的问题。