后端能力地图
后端技术常被列成一串产品名：Java、Spring Boot、MySQL、Redis、Kafka、Docker、Kubernetes。产品清单可以说明使用过什么，却不能说明一个请求为何没有进入应用、一次事务为何没有回滚、缓存中的旧值由谁纠正、服务拆分后为什么更难发布，或者预发环境为何获得了生产写入权。
同样使用 MySQL，启动实例、守住并发约束、解释锁等待、完成可回退迁移，需要的是不同能力。Controller 也一样：返回 JSON 只是起点，接口还要约束输入与权限，留下可以关联的运行记录，并在调用结果不明确时找到业务终态。
这张地图用五条观察轴组织后端系统，再把它们映射到站内 25 个知识域。编号用于定位目录，不代表所有人必须按 01 → 25 逐篇通读。初次学习可以沿主干逐步建立模型；开发功能、处理故障或评估架构时，应从当前对象进入首查域，只回补真正缺少的前置。
后端能力由哪些观察轴组成
一个最小服务同时落在五条轴上
以“创建订单”的 HTTP 接口为例。一次看似简单的请求，至少同时涉及五条关系：
请求与协议轴
URL → DNS → 连接/TLS → HTTP → 入口映射 → 业务结果 → 响应
代码与运行轴
源码 → 依赖/编译/测试 → 制品 → JVM/进程 → socket → 就绪/停止
状态与一致性轴
订单事实 → 本地事务 → 缓存/读模型 → 消息/任务 → 对账与纠错
边界与协作轴
模块 → 服务契约 → 身份/权限 → 远程调用 → 分布式状态
变更与证据轴
测试 → 发布环境 → 日志/指标/Trace → 容量/可靠性 → 回退或向前修复第一条轴回答请求怎样到达、被解释并返回。第二条轴回答代码怎样形成制品，制品又怎样成为占用 CPU、内存、文件描述符和端口的进程。第三条轴回答哪些数据是权威事实，事务、缓存、消息与索引怎样保持或恢复一致。第四条轴回答责任放在哪个模块或服务，调用方以什么身份获得哪些资源权限。第五条轴回答一次变化如何被验证、部署、观察和恢复。
五条轴会交叉穿过同一个现象。线程池耗尽可能起于远程依赖没有超时，最后表现为 HTTP 超时；错误的环境凭据可能让请求与代码都正常，却把状态写入生产账号；缓存旧值既可能来自消息积压，也可能来自失效职责不清。排查时先找到能够区分这些原因的对象，再进入对应知识域。
主干能力、横切能力和支撑系统职责不同
语言、JVM、网络、Web 容器、框架、数据库、缓存和消息通常构成应用的执行主干。它们决定代码在哪里执行、请求怎样流动、状态保存在哪里、依赖怎样交互。只学习 API 用法而不理解对象生命周期和失败语义，遇到组合问题时就只能反复改配置。
安全、测试、可观测、可靠性、契约和工程质量从第一个接口就开始发挥作用。接口要拒绝未认证和越权请求，用成功用例与关键反例固定行为，以稳定错误结构和关联标识留下诊断入口，并为远程调用设置超时。模块依赖也应由代码规则约束。OWASP Application Security Verification Standard提供了设计和验证 Web 应用安全控制的要求入口，具体项目再按数据、主体和威胁选择适用级别。
初学者可以先给订单接口加入输入校验、授权拒绝和自动测试。当系统出现多种主体、跨服务 Trace、重试与幂等、版本兼容或架构例外时，再进入 15、16、17、19、23、24 域深化。基础动作随代码一起建立，完整专题则在复杂度真正出现时展开。
IDE、Git、Maven、Docker、数据库客户端和 Kubernetes 分别支撑构建、运行、观察与部署。Kubernetes Concepts Overview从集群、工作负载、服务、存储、配置和安全等对象组织编排平台，应用仍要为自己的契约与数据结果负责。容器健康、Deployment 收敛和日志平台绿色各自回答不同问题，业务事务、Schema 兼容与用户结果还需对应检查。
对象、机制和证据构成一项能力
学习一个知识域时，可以用三类问题判断理解是否完整：
| 维度 | 需要回答的内容 | 订单接口示例 |
|---|---|---|
| 对象与边界 | 系统中实际存在什么，谁拥有生命周期或写入权 | request、进程、订单表、工作负载身份、下游账号 |
| 机制与条件 | 对象怎样变化，哪些条件成立时结论才成立 | 事务代理何时生效、连接何时复用、消息何时可能重复 |
| 证据与恢复 | 怎样证明运行事实，失败后怎样回到可确认状态 | Trace、SQL 审计、下游收据、对账、补偿、兼容回退 |
记住对象名称只能形成术语表，跑通正向 Demo 也会把未知条件留到生产；一开始背诵大量监控指标，又容易忘记它们保护的对象。更有效的路径是先得到最小正向结果，再制造一个关键反例，解释观察结果为何变化，最后补上生产约束与恢复方法。
识别对象与边界
→ 得到最小正向结果
→ 制造关键反例
→ 用运行证据解释机制
→ 在容量、安全和变更条件下取舍
→ 完成发布、恢复与复验这条进阶关系用于识别能力缺口，不规定每篇文章的结构，也不构成小改动的审批流水线。任务风险越高、影响越难撤销，验证和恢复就需要走得更深。
为什么不能只按技术栈或编号学习
产品名不会自动形成系统模型
“学完 Spring Boot 再学 MySQL，然后学 Redis 和 Kafka”隐含了错误假设：产品之间存在稳定的课程顺序。实际上，Redis 可以承担缓存、锁、限流或消息等不同责任；Kafka 可能用于业务事件、日志管道或数据集成；同一个 Spring Boot 应用也可能完全不需要它们。
学习入口应由问题决定。订单查询过慢时，先确认是 SQL、连接池、缓存回源、线程等待还是网络尾延迟，再进入对应域；不能因为系统使用 Redis 就先归因缓存。准备增加消息队列时，要先说明同步路径的当前问题、消息代表的事实、交付与重复语义、积压和恢复责任，不能从产品功能表反推架构需求。
产品升级也会改变细节。Java 与 Spring Boot 的支持区间、数据库版本、容器运行时和 Kubernetes API 都会演进。地图只提供稳定对象关系，具体版本必须进入对应专题并核对当前官方文档。例如 Spring Boot System Requirements给出当前版本对 Java、构建工具和容器的要求，不能用记忆中的旧版本范围替代。
目录编号用于寻址，前置依任务变化
本站 01—25 按知识组织编号，便于导航和引用。具体任务所需的前置通常只是若干能力切片，无须完整读完所有较小编号。微服务边界需要网络、数据、观测、可靠性和契约基础，其中一些完整专题排在 13 之后：先掌握当前任务的最小动作，复杂度出现后再专项深化。
专题前置 ≠ 必须读完所有较小编号
最小前置示例：
远程调用前 → HTTP/连接、超时、错误结构、关联标识
异步消息前 → 权威事实、本地事务、重复处理、可查询终态
服务拆分前 → 模块边界、数据写入权、独立收益、故障恢复
生产发布前 → 不可变制品、环境身份、拒绝路径、回退条件跳读本身没有问题。问题在于缺少前置却继续堆叠组件。例如不理解本地事务就直接设计分布式事务，不理解进程和就绪就只会调 Kubernetes 探针，不理解 HTTP 方法与错误语义就先建立 API 网关规则。此时应回补具体缺口，而不是重新从 01 通读所有内容。
五篇基础课先建立共同坐标
第一次系统学习后端，建议在能力地图之后依次阅读五篇基础长文：
| 顺序 | 入口 | 读完应能解释什么 | 暂时不要求什么 |
|---|---|---|---|
| 1 | 从请求到响应 | URL、域名、DNS、连接、TLS、HTTP、代理、Servlet/MVC、业务和响应怎样组成完整请求链 | 不要求先掌握所有框架源码和网络内核实现 |
| 2 | 从代码到进程 | 工程、依赖、编译、测试、制品、JVM、进程资源、监听、就绪和停止怎样衔接 | 不要求先建立生产流水线和容器平台 |
| 3 | 从一次写入到一致状态 | 权威事实、事务、幂等、缓存、消息、版本和对账怎样共同形成可收敛状态 | 不要求先搭建完整消息与缓存平台 |
| 4 | 单体、模块化单体与微服务 | 代码、制品、部署、数据、调用、故障、容量和团队责任怎样共同决定边界 | 不把微服务当作必然终点 |
| 5 | 开发、测试、预发与生产环境边界 | 同一候选怎样晋级，配置、身份、数据、依赖和生产 authority 为什么必须隔离 | 不要求凑齐四套固定环境 |
这个顺序先从外部可观察的请求建立全景，再解释服务怎样被构建和运行；理解权威状态、重复与收敛之后，再扩大到服务边界与环境变更。排查问题时也可以从源码和进程向外展开，两种视角能够互相校验。推荐顺序服务首次理解，故障入口仍由现象决定。
五篇基础课建立的是小服务的共同坐标：请求链、构建运行链、权威与派生状态、数据与依赖关系，以及制品进入不同环境后取得的身份和权限。能够画出这些关系，并知道问题应进入哪个专题继续验证，就具备了进入后续领域的基础。
CRUD 只是业务路径的一部分
能够完成增删改查是必要起点。继续进入生产后，同一接口还会遇到并发冲突、事务提交、权限拒绝、版本兼容、外部结果未知、容量上限与故障恢复。本机的一次 200 记录了某组输入经过当前路径；生产权限、超时重放、版本共存和停机期间的任务处理，需要另外的实验与运行记录。
进阶首先体现在本地事务、模块边界、错误契约、测试、日志和恢复是否扎实，而非中间件数量。当前边界持续出现独立发布、容量、故障或合规收益，并且团队能够承担新增运行责任时，跨进程拆分才有充分理由。
怎样从 01 进入 25 个知识域
01：工程入口与学习路径
01 域建立共同坐标，不替代后续专题。它把请求、制品、进程、服务、数据权威、environment 和 authority 放在同一张图中，并给出五篇基础课的正反实验。完成这一域后，至少能把“应用坏了”改写成更具体的判断：名称解析失败、端口未监听、请求已进入 MVC、事务结果未知、派生状态落后、服务边界耦合，或低环境获得了生产权限。
| 编号与入口 | 解决的问题 | 最低前置 | 首个有效证据 |
|---|---|---|---|
| 01 工程入口与学习路径： 请求 · 进程 · 状态 · 架构形态 · 环境 | 源码、制品、进程、端口、请求、状态、依赖和环境怎样组成系统 | 能运行一个小程序并使用终端 | 能画出最小服务的五条轴，并根据现象选中后续知识域 |
还不能运行程序、阅读基本控制流或使用终端时，应先补编程与计算机基础。Learn Java提供 JDK 安装、第一段程序、语言、API、模块与 JVM 工具的官方学习入口。本站 01 域从“可以运行并观察一个程序”开始，不承担完整语法课程。
02—09：理解 Java 进程和请求入口
这一组把代码内部与网络入口接起来。Java 决定类型和错误如何表达，JVM 决定 class、对象、线程和执行，网络与 Servlet/Web 容器把字节流转换为请求对象，Spring 再完成对象装配、代理、配置和 MVC 契约。
| 编号与入口 | 核心对象 | 最低前置 | 首个有效证据 |
|---|---|---|---|
| 02 Java 语言与工程基础 | 平台版本、类型对象、泛型、集合、异常与运行时元数据 | 01 代码与进程坐标 | 固定 JDK 基线，并用类型、集合和异常表达一条业务数据路径 |
| 03 JVM 运行时机制 | class、对象、内存、GC、JIT、诊断 | 02 Java 基线 | 用 JVM 证据解释一次加载、内存、停顿或编译现象 |
| 04 Java 多线程与并发 | 线程、任务、取消、共享状态、锁、队列 | 02 Java；03 运行时基础 | 让任务可取消，并解释一次等待、竞争或过载 |
| 05 网络与 Web | DNS、IP、TCP/QUIC、TLS、HTTP、代理、连接池 | 01 请求与进程坐标 | 把一次失败定位到名称、连接、TLS、HTTP 或超时边界 |
| 06 Servlet 与 Java Web 容器 | 容器、请求/响应、Filter、线程、异步、会话 | 03 JVM；05 网络 | 沿容器生命周期追踪一次同步或异步请求 |
| 07 Spring Framework 容器与代理 | BeanDefinition、实例、代理、事务拦截 | 02 Java 对象模型 | 从定义追到实例与代理，并确认拦截是否发生 |
| 08 Spring Boot 开发与应用装配 | 业务接口、Lombok、MyBatis-Plus、配置、自动装配、健康、打包 | 06 Web 容器；07 Spring | 实现带校验与数据库事务的业务，解释应用装配和运行结果 |
| 09 Spring MVC 请求运行时 | 映射、绑定、校验、异常、内容协商、响应写出 | 05 HTTP；06 Servlet；07 Spring | 追踪 DispatcherServlet 全链，并验证成功与错误响应 |
最小接口可以在掌握完整 JVM 机制之前完成。随着现象变复杂，再按专题顺序补足解释力。RFC 9110定义 HTTP 的共同语义，/proc/<pid>/status展示 Linux 进程身份、状态和资源字段，两类资料对应请求轴与运行轴的不同观察面。
10—15：管理权威状态和跨边界协作
当服务开始保存数据、引入缓存、异步消息或远程服务，核心问题从“代码能否执行”转向“哪个事实由谁拥有，失败后怎样收敛”。安全在这一组作为独立专题深化，但身份、授权和敏感数据控制从第一条请求就已存在。
| 编号与入口 | 核心对象 | 最低前置 | 首个有效证据 |
|---|---|---|---|
| 10 数据访问与持久化 | 连接、事务、SQL、映射、锁、Schema | 02 Java；关系模型与 SQL | 证明本地事务提交或回滚，并用执行证据定位查询问题 |
| 11 应用缓存与派生状态 | 真相源、缓存项、失效、热点、降级 | 10 数据权威 | 指出权威数据，复现不一致窗口并验证恢复 |
| 12 消息系统与事件流 | 事实、消息、交付、重复、顺序、积压 | 10 本地事务；契约与可靠性基础 | 写出投递不变量，验证重复处理和失败恢复 |
| 13 微服务与 Spring Cloud | 服务边界、发现、路由、远程治理 | 05 网络；10 数据；观测/可靠性/契约基础 | 用独立交付或隔离证据证明拆分收益，并列出新增失败状态 |
| 14 分布式系统与状态协调 | 分区、复制、选主、时间、跨服务状态 | 10 状态；13 远程边界；观测与可靠性基础 | 声明目标一致性，验证部分完成后的收敛 |
| 15 后端身份与安全防护 | actor、workload、凭据、权限、数据、威胁 | 01 系统边界；05 请求链 | 画出信任边界，证明未认证、越权和敏感数据路径被拒绝 |
进入数据访问前应理解关系、表、主键、约束、查询和事务。PostgreSQL 官方教程可以建立第一条 SQL 与事务路径；具体工程仍要进入 10 域，处理连接池、映射、锁、隔离级别和迁移。
缓存、消息和微服务都在增加状态副本或远程边界。增加组件前，应先写出权威事实、允许的延迟、重复与未知结果、故障时可接受行为和纠错责任。没有这些定义，更多组件只会把原本清晰的本地错误变成跨系统不确定性。
16—19：用证据限制变更和故障
这一组把“感觉正常”变成可重复、可关联和可行动的证据。测试在变更前制造输入和反例，可观测性保存运行中的信号，性能工程解释资源与排队，可靠性限制失败传播并确认恢复。
| 编号与入口 | 核心对象 | 最低前置 | 首个有效证据 |
|---|---|---|---|
| 16 后端测试与验证体系 | 单元、组件、集成、契约、端到端、fixture | 一个可执行行为或契约 | 按边界选择测试层，让关键反例在变更时稳定失败 |
| 17 后端日志、指标与链路 | event、metric、trace、resource、关联标识 | 01 运行边界；05 请求链 | 用同一时间窗和关联标识定位一次跨依赖请求 |
| 18 后端性能与容量工程 | 延迟、吞吐、并发、利用率、队列、瓶颈 | 17 观测；相关资源域 | 固定负载条件，找出最窄资源并验证优化没有转移瓶颈 |
| 19 后端可靠性与故障控制 | deadline、重试、幂等、隔离、降级、恢复 | 05 网络；17 观测；相关依赖域 | 制造受控故障，证明影响被限制且恢复终态可确认 |
日志、指标和 Trace 提供三种信号模型，无须被绑定成统一产品采购。OpenTelemetry Observability Primer区分 traces、metrics 和 logs，并解释 resource 与 context 的作用。工具选择应从需要关联的请求、实例、依赖和业务终态出发。
重试只在操作可安全重复、剩余 deadline 允许、错误属于暂时性失败且调用方承担责任时帮助恢复。写操作结果未知时，先用 operation ID 查询或对账；直接重放可能把一次不确定结果放大成重复副作用。
20—25：完成长期交付与可逆演进
这一组处理请求之外的长期任务和系统变化：调度任务、文件、搜索、API/数据契约、代码结构和综合架构演进。它们往往横跨前面多个域，因此前置由具体变化决定，不存在一条统一串行课程。
| 编号与入口 | 核心对象 | 最低前置 | 首个有效证据 |
|---|---|---|---|
| 20 后端调度与异步任务 | schedule、fire、attempt、租约、重复、恢复 | 04 并发；10 事务；19 可靠性基础 | 同一任务重复触发仍正确，中断后可以确认恢复 |
| 21 后端文件与对象存储 | 流、对象、授权、完整性、生命周期 | 05 HTTP；06/09 请求；15 安全基础 | 验证限流上传、越权拒绝、完整性和清理 |
| 22 后端搜索与分析 | 索引、映射、同步、查询、别名、重建 | 10 数据；12 事件；19 可靠性基础 | 定义映射，验证同步延迟并完成可回退重建 |
| 23 后端 API 与数据契约 | HTTP、事件、Schema、消费者、兼容窗口 | 05 HTTP；16 测试基础；真实消费者 | 运行兼容测试，证明旧消费者在演进期间仍可工作 |
| 24 后端工程结构与代码质量 | 模块、依赖、DDD 模型、用例、错误、配置 | 02 Java；08 Spring Boot 开发；16 测试基础 | 从业务规则建立模型和事务，用测试与依赖检查支持后续修改 |
| 25 后端架构演进综合实战 | 现状证据、候选方案、迁移、灰度、回退 | 与目标变化相关的全部前置域 | 提交包含收益、新失败面、验证、迁移和回退的决策 |
20—22 处理请求结束后的批任务、可能携带巨大负载与敏感内容的文件，以及需要重建的搜索索引。这些能力同样依赖权威事实、身份、容量和恢复模型。
25 域把一次真实变化重新放回前面各轴：变化原因、责任位置、新增失败状态、数据迁移、版本共存，以及出错后的停止、回退或向前修复。保持单体、拆分服务、合并服务和替换组件都可能成为最终方案。
怎样按当前任务选择路线并判断学会
从任务对象选择入口
选择入口时，先把问题写成“对象 + 现象/目标 + 当前证据”，再找能够区分下一步的首查域：
当前任务或现象
└─ 哪个对象首先偏离预期
└─ 哪个知识域能解释该对象
└─ 当前缺少哪一项最低前置
└─ 下一份可以证伪判断的证据是什么“Kafka 有问题”无法提供定位入口。改写为“订单事件已提交到 outbox，但消费者组积压持续增加，重复处理计数上升”后，就可以从 12 消息与事件进入，并根据观察结果继续到 10 事务、17 观测或 19 可靠性。“Spring Boot 启动失败”也应继续区分 class 加载、配置绑定、Bean 创建、端口、迁移和依赖连接。
六类常见任务有不同主路线
| 任务 | 推荐主路线 | 第一份完整结果 |
|---|---|---|
| 零基础 Java 后端 | 01 → 02 → 05 → 06/07/08/09 → 10，并从第一接口加入 15/16/17/19/23/24 基础动作 | 一个有 HTTP 契约、本地事务、授权拒绝、自动反例和关联日志的模块化单体 |
| 新功能交付 | 业务结果 → 23 契约 → 10 权威状态 → 所需依赖域 → 15/16/17/19 → 环境边界 | 输入、成功、拒绝、失败、数据提交、观测和发布边界能够共同解释 |
| 线上故障 | 用户现象 → 05/09 请求入口 → 08/03/04 运行实例 → 10—14 状态依赖 → 17/19 证据与恢复 | 同一时间窗内能关联请求、实例、依赖和业务最终状态 |
| 性能容量 | 目标 SLO → 17 信号 → 18 负载与资源 → 实际瓶颈所属域 → 19 过载行为 | 固定负载下定位队列和最窄资源，优化前后结果可比较 |
| 服务拆分或合并 | 架构形态 → 10 数据权威 → 13/14 远程状态 → 17/19/23 → 25 迁移 | 以独立收益和运行代价说明边界，包含兼容、迁移、回退与 owner |
| 环境与发布 | 代码到进程 → 环境边界 → 08 配置/健康 → 15 身份 → 16/17/19 → 部署运维 | 已验证摘要晋级，运行输入隔离，反向访问被拒绝，下游事实可追溯 |
路线中的“→”表示当前任务的主要承接，其他域仍按实际现象加入。新功能可能完全用不到缓存和消息；线上故障可能从数据库收据直接定位到 10；服务拆分评估也可能得出保持模块化单体。它帮助减少无依据的跳转，不规定项目必须采用什么技术栈。
从现象选择首查域
| 当前现象或目标 | 首查域 | 证据继续指向时再查 |
|---|---|---|
| 域名失败、连接或 TLS 超时，请求未得到 HTTP 响应 | 05 网络与 Web | 17 观测、19 可靠性、平台网络 |
| 已有 HTTP 响应，但状态、错误体、绑定或媒体类型不符合契约 | 09 Spring MVC | 05 HTTP 语义、23 API 契约 |
| 服务未启动、端口未监听、制品无法运行 | 代码到进程 | 03 JVM、08 Spring Boot、17 可观测 |
| 启动成功但 readiness 失败或实例反复重启 | 08 Spring Boot | 03 JVM、10 数据、19 可靠性、部署运维 |
| 线程堆积、任务停不下来、CPU 与吞吐不匹配 | 04 并发 | 03 JVM、18 性能、19 可靠性 |
| 事务未回滚、锁等待、连接耗尽或 SQL 变慢 | 10 数据访问 | 07 Spring 代理、17 观测、18 性能 |
| 缓存出现旧值、热点、击穿或回源异常 | 11 缓存 | 10 权威数据、17 观测、19 可靠性 |
| 消息重复、丢失、乱序、结果未知或积压 | 12 消息与事件 | 10 事务、14 分布式、17 观测、19 可靠性 |
| 未认证访问、越权、凭据或敏感数据泄露 | 15 安全 | 05 网络、17 审计、23 契约、24 工程质量 |
| 低环境连接生产资源或不同环境行为无法解释 | 环境边界 | 08 配置、15 身份、17 观测、部署运维 |
| API 或事件升级导致旧消费者失败 | 23 契约 | 16 测试、12 消息、25 迁移 |
| 准备拆分、合并或重划服务边界 | 架构形态、13 微服务 | 10 数据、14 分布式、17/19/23、25 演进 |
| 准备替换数据库、缓存、消息或搜索系统 | 对应状态域 10/11/12/22 | 16 验证、17 观测、19 可靠性、25 演进 |
首查域提供第一个区分条件，根因仍要继续验证。DNS 正常后可以转查 TLS，HTTP 200 后还要核对业务账本，线程等待则可能指向数据库连接池。每一步建立一个可靠事实，再把剩余不确定性移交给下一域。
用可复验结果判断“学会到哪一层”
能力深度可以从实际完成的动作判断：
| 层次 | 能够完成的事情 | 尚不能据此声称 |
|---|---|---|
| 使用 | 按明确条件运行最小示例并得到预期结果 | 理解所有内部机制或能直接用于生产 |
| 解释 | 说清关键对象、生命周期、条件与失败语义 | 已覆盖并发、容量、安全和版本变化 |
| 验证 | 设计正向与反向实验，用证据排除替代解释 | 已经具备生产恢复和长期治理能力 |
| 负责 | 在真实约束下完成权限、容量、发布、观测、恢复和复验 | 所有规模和团队都应采用同一方案 |
| 演进 | 以运行证据触发调整，迁移时保持兼容并可停止或恢复 | 架构会永久稳定或组件越多越成熟 |
不同任务只需要达到相称层次。个人练习可以先完成“使用与解释”，生产写路径至少要有验证、权限和恢复；跨团队服务边界还需要契约、观测、值守和演进责任。学习记录应保存自己能够复验的代码、测试、命令输出、设计决策和故障复盘，而不是只统计文章数量和产品名。
后端开发、工具效率与部署运维如何分工
本站三个知识体系会在同一对象上相遇，但各自回答不同问题：
| 知识体系 | 主要职责 | 典型入口 |
|---|---|---|
| 后端开发 | 应用对象、协议、数据、并发、框架、契约和故障机制 | 为什么发生、代码与边界怎样设计、怎样验证 |
| 工具效率 | 开发机工具、产品安装、控制台、命令和日常操作 | 怎样在本地或受控环境正确使用具体产品 |
| 部署运维 | 生产主机、集群、网络、发布、备份、监控平台和值班流程 | 怎样运行、保护、扩缩、恢复和持续运营生产系统 |
后端文章仍会给出为理解机制所必需的 Linux、Docker、curl、浏览器开发者工具和 Kubernetes 命令；工具文章也会解释操作边界；运维文章会涉及应用配置和健康语义。分工按读者任务和责任闭环，而不是禁止交叉。
当前问题已经落到知识域、最低前置明确，并且能够写出下一份可证伪的观察项时，就可以离开地图进入对应专题。地图用于减少错误入口、产品堆叠和无依据的架构跳跃，逐项勾完 25 个编号并无额外价值。
权威资料与规范地址
以下资料提供语言起步、协议、进程、框架、数据、观测、安全和编排的第一入口。地图只引用共同坐标；具体版本、机制与操作以对应专题中的规范和官方文档为准。
语言、协议、进程与框架
| 资料 | 地址 |
|---|---|
| Dev.java — Learn Java | https://dev.java/learn/ |
| RFC 9110 — HTTP Semantics | https://www.rfc-editor.org/rfc/rfc9110.html |
Linux manual — /proc/<pid>/status | https://man7.org/linux/man-pages/man5/proc_pid_status.5.html |
| Spring Boot — System Requirements | https://docs.spring.io/spring-boot/system-requirements.html |
数据、观测、安全与编排
| 资料 | 地址 |
|---|---|
| PostgreSQL — Tutorial | https://www.postgresql.org/docs/current/tutorial.html |
| OpenTelemetry — Observability Primer | https://opentelemetry.io/docs/concepts/observability-primer/ |
| OWASP — Application Security Verification Standard | https://owasp.org/www-project-application-security-verification-standard/ |
| Kubernetes — Concepts Overview | https://kubernetes.io/docs/concepts/overview/ |