看过答案，离能独立解释还有一步
整理项目时，我发现一个常见落差：看见“幂等”“背压”“缓存失效”会觉得熟悉，但合上资料以后，未必能从具体失败场景讲出完整过程。
我把面试研习社当作把知识和表达接起来的练习入口。当前导出的题库有 720 条记录，分为 11 个专题，覆盖 AI、C++、Python、前端、数据库、网络和系统等方向。数量说明材料范围，不代表每条题目都已经掌握。
先独立回答，再展开对照
阅读模式适合第一次建立概念，自测模式则把顺序反过来：先回答，再看参考内容，对照缺了哪些前提、步骤与边界。
例如问“异步下单怎么保证不超卖”，我会先在纸上写出四个点：请求持久化、Redis 准入、数据库条件扣库存、重复消费处理。然后对照 FlashFlow 的实现，检查有没有把“202 已接单”误说成“已经出票”。
如果一句话里用了自己不能展开的术语，就把它留成下一轮问题。这样的复习比把整个参考答案背成一段更容易发现缺口。
三种自评，对应不同的后续安排
网站把自评分成“没记住”“有印象”“能讲清”。review-scheduler.js 用复习事件重建状态，间隔序列是 1、3、7、14、30 天。
这是项目自定义的启发式规则，不是 SM-2，也没有依据声称它适合所有人的记忆曲线。它的目的很具体：把“下一次什么时候回来检查”变成可以执行的安排。
首次选择“能讲清”后先隔一天复习，后续再逐步延长。答不上来会把进度退回短间隔；“有印象”也会让下一次复习更早。同一天反复点“能讲清”，不会每次都继续往上升级，避免把按钮次数误当成掌握程度。
为什么保留事件，而不只保存一个等级
当前记录保留事件 ID、时间和自评等级，调度器先去重、检查时间范围，再按顺序计算状态。这样同步后的结果可以由事件重新推导，也更容易解释某道题为什么到期。
一天按北京时间划分，跨设备的时间来源也需要考虑。代码在取得服务器时间后，用本地经过时间推进当前时刻，减少设备时钟随意跳动带来的影响。
这些工程细节没有让复习变成一套精密的记忆预测，却能避免一些明显错误：重复事件算两次、未来时间把安排推远、跨时区让同一天变成两天。
项目回答可以固定成四个问题
复习一项能力时，我会把答案写成一小张卡片：
| 问题 | 我希望讲出的内容 |
|---|---|
| 当时处理什么问题？ | 一种能复现的失败或限制 |
| 代码做了什么？ | 状态、顺序、约束和对应模块 |
| 用什么验证？ | 测试入口、实验条件或可回查产物 |
| 仍然有什么边界？ | 没覆盖的场景及真实代价 |
MiniRedis 可以讲慢客户端与部分发送；CodeRAG 可以讲索引版本与统一评分；洛谷工作台可以讲草稿证据和有限复核。同一个基础概念，放到不同项目里比较，回答会更具体。
限时模拟检查的是连续表达
单题看懂以后，可以在限时模拟里连续回答几个相关追问，观察自己在哪一步开始绕圈。知识地图和搜索用于补回缺口，统计页用于看近期是否真正留下了学习记录。
公开面经提供的是外部提问视角。它们应保留来源，不能写成自己的面试经历；本站整理的参考答案也不代表公司的标准答案。
另外，当前学习网站的服务器记录是共享空间，所有访客可修改；浏览器中的筛选和阅读位置则属于另一类本地状态。写笔记前需要分清保存位置，不把共享练习页当作私密材料存储。
我想保留的习惯，是每次复习都让一处模糊的表述落到源码或例子上。会背结论之后，仍要继续追问：如果这里失败了，系统还剩下什么？