用 OpenSpec 给 AI 编码助手加一层规范:先对齐,再写代码
OpenSpec 是面向 AI 编码助手的规范驱动开发工具,先把需求写成可审阅的 spec,再让 AI 动手写代码,把跑偏的纠错成本从几百行代码压到一段提案。
OpenSpec 是面向 AI 编码助手的规范驱动开发工具,先把需求写成可审阅的 spec,再让 AI 动手写代码,把跑偏的纠错成本从几百行代码压到一段提案。
索引不是免费的。这篇从写入侧讲起:顺序追加和随机插入在 B+ 树上的两副面孔、页分裂怎么发生、change buffer 攒的是什么;然后用一组 EXPLAIN 输出对照五个最常见的索引失效场景,每个给反例和改法。
InnoDB 的表本身就是一棵 B+ 树——这是理解一切索引行为的总开关。这篇拆开聚簇索引和二级索引的叶子存了什么,回表的成本从哪来,联合索引 (a,b,c) 的列顺序在树里怎么排,以及索引下推省了哪一步。
从一条慢查询出发,把哈希表、有序数组、二叉树、B 树逐个放到索引这个位置上称重,看 B+ 树凭什么胜出;再打开 InnoDB 的 16KB 页算一笔账,解释"2000 万行、3 层树"这个数字的来历。
FastAPI 配 SQLAlchemy 2.0 的 async 写法:create_async_engine、async_sessionmaker、2.0 风格 select 做 CRUD、连接池与事务,并用依赖注入把 DB session 干净地挂到每个请求上。顺带讲清同步/异步的边界。
FastAPI 的三种参数来源(路径/查询/请求体)如何从类型注解自动解析校验,以及 Depends 依赖注入如何把鉴权、数据库连接、公共逻辑做成可复用的层级结构。
FastAPI 的校验能力全部来自 Pydantic v2。从 BaseModel 定义、Field 约束、嵌套与联合类型,到请求模型与响应模型分离、序列化控制,把「数据长什么样、哪些合法」用代码精确锁死。
从技术底座(Starlette + Uvicorn + Pydantic)、类型注解驱动、原生异步与自动文档四个角度,讲清 FastAPI 为什么代表 Python Web 的现代范式,以及它和 Flask / Django 的取舍。
FastAPI 接口上线前要做的事:OAuth2 密码流 + JWT 签发校验、密码哈希、CORS、自定义中间件与后台任务,以及用 gunicorn+uvicorn 部署和 pytest 依赖覆盖测试。这是 FastAPI 五篇系列的收尾。
上线不是把代码推上去就完事。用"代码对不对、数据会不会丢、扛不扛得住、出问题能不能发现、能不能撤回来"五个问题,把上线前的检查项串成一条清晰的逻辑链。