Servlet 在 Java Web 体系里到底处在什么位置，HTTP 请求究竟是怎样一路走到你的业务代码里的。

哪怕 2025 年了，JDBC 仍然是 Java 后端开发的“必修底层课”：它不时髦，但永远躺在调用栈最下面；它露出很少，但一出问题就是大问题；理解它，不是为了多写几行原生 JDBC，而是：让你在面对 ORM 和连接池时，真正知道自己在干什么。

这篇文章刻意把「配置管理」和「日志」放在一起聊，目标只有一个，就是帮你建立一套统一的“世界观”： Spring 里配置怎么流动，日志怎么流动，它们如何一起在云原生架构里协同工作。

为什么 Spring 世界一定要单独搞一个「Bean」这个名词？`@Component`、`@Service`、`@Repository` 这些注解到底算什么？它们和我们心里的「组件」到底是同一类东西，还是两个世界？

学 Maven，不是为了“背命令、背 XML 标签”，而是为了在脑子里多长出一条“从源码到制品”的清晰流水线。当这条线清晰之后，你在 Java 世界做的所有工程化选择 —— 无论是 Spring、Gradle、Docker 还是 K8s —— 都会有一个更稳的落点。

帮你搭一张 “从网络到 Java Web 的全景图”：用 七层网络模型 搭一个坐标系；把 HTTP / TCP / Socket / NIO / Netty 放回各自的位置；再看 Servlet / Spring MVC / WebFlux 各自站在哪一层。

Virtual Thread 不是“新一代 ThreadPoolExecutor”，而是把原来那个沉重的 `Thread` 拆成了两层：底层少量 平台线程（OS 线程）；上面跑着大量 虚拟线程（Virtual Thread）。

flatMap 到底在干嘛？为啥一会儿是 `T -> Stream<R>`，一会儿又变成了扁平的一维流？

我不会再问‘到底该选 Spring Cloud 还是 K8s 还是 Mesh’，我会先问：这件事应该放在 应用层、平台层还是网络治理层？框架只是实现，分工才是底层逻辑。

在 CI/CD 和运维里，最有价值的不是某个工具，而是“经验往左推”的速度：把线上踩过的坑、解决过的问题，变成「测试 + 规范 + 自动化」的速度。