目标读者是一个从零动手的 coding agent：没有参考源码、没有历史对话，只拿到这份文档，也能写出可运行、可自证正确的解密实现，并且知道哪一步可以宣称成功、哪一步不能。
这个承诺的适用范围要说清楚：拿到密钥之后的部分——页面格式、认证、逐页解密、WAL、验收——是完整可实现的；取得密钥的部分只对第 5.2 节的形态 A 完整，形态 B 需要针对具体版本另行分析，第 5.3 节只给原理与参数，不保证够用。
范围是 macOS 上 WX 4.x 的本地 SQLCipher 数据库，即其数据根目录下 db_storage 里的 .db 文件。不涉及服务端、不涉及其他键值存储格式、不涉及自动发布、不提供绕过系统保护的通用手段。自写完整的 WAL 恢复器也不在范围内：第 8.4 节只给受限恢复路线，完整恢复走第 8.5 节。
| /* ============================================================ | |
| Yuque-style Minimal Typography for Obsidian (macOS) | |
| Author intent: Chinese-first readability, calm rhythm, | |
| long writing friendly, default theme safe. | |
| ============================================================ */ | |
| /* ----------------------------- | |
| 1. Core variables | |
| ----------------------------- */ | |
| :root { |
从2003年开始，在Web应用领域，ORM(对象-关系映射)框架就开始逐渐普及，并且流行开来，其中最广为人知的就是Java的开源ORM框架Hibernate，后来Hibernate也成为了EJB3的实现框架；2005年以后，ORM开始普及到其他编程语言领域，其中最有名气的是Ruby on rails框架的ORM － ActiveRecord。如今各种开源框架的ORM，乃至ODM(对象-文档关系映射，用在访问NoSQLDB)层出不穷，功能都十分强大，也很普及。
然而围绕ORM的性能问题，也一直有很多批评的声音。其实ORM的架构对插入缓存技术是非常容易的，我做的很多项目和产品，但凡使用ORM，缓存都是标配，性能都非常好。而且我发现业界使用ORM的案例都忽视了缓存的运用，或者说没有意识到ORM缓存可以带来巨大的性能提升。
| [user] | |
| name = robbin | |
| email = fankai@gmail.com | |
| [color] | |
| ui = true | |
| [alias] | |
| co = checkout | |
| ci = commit | |
| st = status |