约 800 本书就在架上。想看哪本直接拿走，扫一下条形码，30 天后还回来。
不用办证，不用找管理员，书架旁边站着就能弄完。
微信扫左边的码进入，或搜索小程序「待填：小程序名称」。
图书角在 待填：楼层与位置。
有问题找 待填：管理员姓名。
没有押金，没有罚款。这是同事之间的书架，靠的是大家自觉。
说明这本书还没登记进系统——多半是有人捐了书直接放上架。 页面上会有个「告诉管理员有这本书」的按钮，点一下就行，管理员那边会收到。 报的人越多，越会被优先补进来。
点「还回来」之后，这本书会进「待确认」状态， 等下一个人扫到它、或者管理员盘点扫到它，就自动确认归位了。 你的借阅记录在你点归还的那一刻就已经结掉了，不会算你头上。
页面上会显示是谁借的、大概什么时候还，可以直接找他商量。 也可以点「有空位时通知我」登记一下——管理员能看到哪些书需求旺，好决定要不要再买一本。
告诉管理员就行，系统里标记一下。 找回来了还能改回来，不是一标记就永远没了。待填：赔偿约定，如果有的话
直接交给管理员登记，扫个码填个书名就好，一本二十秒。 也可以说一声想看什么书，攒够几个人就一起买。
上面是使用说明，到这儿就够了。 下面是设计取舍和踩过的坑——对怎么实现不感兴趣的话，可以关掉了。
图书角不是小型图书馆。图书馆的核心问题是检索和调度，图书角的核心问题是书会消失。
书架摆八百本，半年后少一百本，没人知道去哪了。所以第一目标不是「让借书更方便」—— 手拿走书本来就很方便——而是让每一本书在任何时刻都有明确的责任人。 这句话决定了后面几乎所有取舍。
到期日 < 现在 算出来的。
一旦把它落成字段就得维护它——每天刷、续借刷回来、还书再刷，
多一个要同步的状态就多一处会不一致的地方，而且极难发现。
为了不部署也能验证，写了个 wx-server-sdk 的内存替身，
用 Module._resolveFilename 把它换进去，跑的是真实的云函数源码而不是重写一遍的逻辑。
73 项断言里抓出这些：
_openid 不会自动注入。
云开发只在小程序端直接写库时注入它，云函数以管理员身份写入时不会。
而这套设计所有写操作都走云函数——15 处查询依赖这个字段，最严重的是登录：
查不到已有用户，每次登录都会新建一个账号。读代码发现不了，部署后也要很久才暴露。微信云开发按量计费，这个规模完全在免费额度内。 书目全量缓存到前端只有约 160KB，把最高频的读操作从数据库挪走了， 搜索零延迟还能离线用。
样式从真实的 WXSS 换算而来，不是重新画的效果图。
看八屏预览 →