Appearance
第一部分|全年路线:先建立深度,再构建产品
第 1 章:12 个月系统学习地图
mermaid
graph LR
subgraph S1 ["阶段一: 核心底座 (1-4月)"]
M1["M1: 语言深度"] --> M2["M2: 网络与系统"]
M2 --> M3["M3: 数据库正确性"]
M3 --> M4["M4: 数据库进阶与缓存"]
end
subgraph S2 ["阶段二: 架构与交付 (5-7月)"]
M4 --> M5["M5: 架构设计与异步"]
M5 --> M6["M6: Linux容器CI/CD"]
M6 --> M7["M7: 安全与可观测性"]
end
subgraph S3 ["阶段三: AI与性能 (8-10月)"]
M7 --> M8["M8: AI应用工程"]
M8 --> M9["M9: AI质量工程"]
M9 --> M10["M10: 性能与容量规划"]
end
subgraph S4 ["阶段四: 商业闭环 (11-12月)"]
M10 --> M11["M11: 产品化与获客"]
M11 --> M12["M12: 商业项目上线收费"]
end| 月份 | 主线方向 | 本月必须交出的确定性成果 |
|---|---|---|
| 1 | 一门语言深入、调试与工程习惯 | 可测试、可分析性能的 API 生产级服务 |
| 2 | 网络与操作系统 | HTTP 请求链路实验与并发竞态问题复现报告 |
| 3 | 数据库与 SQL 正确性 | 事务正确的订单 / 账户余额转账模块 |
| 4 | 数据库进阶与缓存策略 | 慢查询诊断、索引优化分析报告与缓存淘汰策略 |
| 5 | 架构设计与异步任务调度 | 模块化单体 + 后台任务队列架构落地 |
| 6 | Linux、容器化与 CI/CD 交付 | 一键部署脚本、自动化测试门禁、数据备份恢复演练 |
| 7 | 安全威胁建模与系统可观测性 | 权限威胁模型(Threat Model)、监控大盘与故障演练 |
| 8 | AI 应用基础工程 | 工具调用(Tool Calling)、结构化输出、调用费用限额管控 |
| 9 | AI 质量工程与大模型评测 | 评测数据集建立、错误归因分类与版本回归门禁 |
| 10 | 性能工程与高可用系统设计 | 容量估算模型、JMeter 压测报告、突发故障应急预案 |
| 11 | 产品化思维与真实获客验证 | MVP 定价策略、10 次非诱导用户访谈、真实付费意愿验证 |
| 12 | 综合项目上线与长期运营 | 可以向外部真实用户持续收费的生产稳定版本 |
学习顺序的深层依据
- 语言、网络、数据库、并发是工程师的底层基石;
- 架构、运维和安全保证系统在真实生产条件下长久稳定可用;
- AI 是现代系统的高效可插拔能力;
- 产品和获客决定你能否真正依靠自己的软件赚到可持续的收入。
自检:先做一份“能力基线(Baseline)”
基线挑战任务:用一周时间独立完成一个小服务——实现**“上传文件 $\rightarrow$ 异步解析 $\rightarrow$ 存储结果 $\rightarrow$ 查询状态”**。
要求:具备用户登录、健全的错误处理、单元测试覆盖、结构化日志记录与 Docker 部署。
完成之后,请诚实回答以下 5 个问题:
- 上传接口在收到网络抖动引发的重复请求时,会不会重复扣费或重复生成两个解析任务?
- 当服务被意外重启、后台 Worker 任务执行中断时,未完成的任务结果是否可以安全恢复?
- 当数据库查询变慢时,你能否拿出底层的执行计划(Execution Plan)分析瓶颈,而不是靠主观猜测?
- 一位普通登录用户能否通过简单修改 URL 中的 ID 参数读取到另一位用户的私密数据?
- AI 大模型接口发生网络超时或熔断后,系统是否有明确的用户降级提示与每用户每日调用费用上限?
IMPORTANT
凡是不能自信、肯定回答的问题,就是你整年学习中最值得重点攻克的章节!
第 2 章:你的主力技术栈应该尽量简单
建议选型主线:
- 前端:TypeScript + React 或 Vue 3
- 后端:Python + FastAPI 或 TypeScript + Node.js
- 主数据库:PostgreSQL
- 缓存/队列:Redis(仅在确有缓存命中或任务队列需求时引入)
- 部署运行:Docker + Linux
- CI/CD 自动化:GitHub Actions(自动化构建与验证)
TIP
这不是唯一的标准答案。你的核心原则应该是:熟练掌握一种主力语言,足够理解第二种语言,切忌为了学习而同时盲目引入五套框架!
如果你已经精通 Java / Spring Boot,完全可以以它为主线深挖,不必强行重学一遍 Python/Node 后端。
什么叫“精通一门语言”?
绝不是指你能熟练背诵多少 API,而是指你能清晰解释:
- 变量和对象如何在底层物理内存中存储与销毁;
- 异常如何在调用栈中传播与被合理拦截;
- 异步并发任务如何在事件循环或线程池中调度;
- 类型系统究竟能为你保证什么、不能保证什么;
- 外部第三方依赖如何安全管理与隔离;
- 代码如何编写高质量自动化测试与精确定位调试;
- 性能瓶颈究竟如何用真实的剖析(Profiling)数据予以证明。
以 Python 为例,你至少应该亲手验证过:
async def、await与多线程池的差异:它们分别适合处理什么类型的系统负载?dataclass/Pydantic:运行时动态校验与 IDE 静态类型检查有什么本质区别?- 上下文管理器(
with语句):资源句柄泄漏为什么极其容易在复杂异常分支中发生? - 生成器与迭代器(
yield):对海量数据处理时的内存占用产生什么决定性影响? - 异常边界划分:数据库底层的原始报错与 SQL 异常应该原样直接暴露给客户端前端吗?
- 性能 Profiling 分析:如何使用 cProfile 或 py-spy 采样数据客观证明系统慢在哪个函数?
动手实验:一个安全的文件解析 API
- 接口定义:
POST /jobs:提交解析任务;GET /jobs/{id}:查询任务当前处理状态。
- 状态机约束:
- 任务状态只能在合法路径之间流转:
queued$\rightarrow$running$\rightarrow$succeeded/failed。
- 任务状态只能在合法路径之间流转:
- 业务与安全限制:
- 每个任务必须严格绑定提交用户,后端服务必须在每次查询和操作时强校验权限;
- 为上传文件设置严格的文件大小上限、MIME 类型白名单、内容安全校验以及最大处理时长超时限制。
验收交付标准:
写出至少 15 个自动化测试用例,覆盖:正常成功流、非法扩展名输入、超大文件阻断、重复提交幂等拦截、水平越权访问拦截、Worker 解析失败降级、服务重启后断点恢复。能够通过结构化日志清晰追踪一次请求从入口网关到数据库的全链路流转!