Book Corner · 250
图书角八屏
公司图书角自助借阅小程序的全部页面。样式从项目里真实的 WXSS 换算而来
（750rpx = 375px），数据取自模拟跑通的那 74 本书、800 册藏本。
8 个页面
74 书目 · 800 藏本
73 项断言全过
微信云开发
2026-08-17
这是静态示例，不是运行截图。
小程序的 WXML/WXSS 要在微信开发者工具里才能真正渲染，而这个项目还没创建小程序、没部署。
这份示例用同一套颜色、字号、间距在网页里复刻出来，用途是在动手部署前先看清长什么样、把动线过一遍。
真机上的差异主要在字体渲染和 scroll-view 的惯性滚动，布局本身一致。
PHASE 0能借能还
最小闭环。这三个页面跑通，图书角就能用了；其余都是让它更好用。
首页
场景是「人站在书架前，一手拿书一手拿手机」，所以只有一个扫码按钮，借和还都走它。
不做「扫码借书 / 扫码还书」两个按钮——用户在架前分不清该按哪个，而系统完全有能力自己判断。
逾期信息放首屏，主动怼到脸上。
扫码结果 · 应用的枢纽
借书、还书、确认归还三件事全在这一页。页面完全由服务端返回的 场景类型 驱动，
前端不做状态推断，六种情形对应六种动作区。
「别人借走了」显示真名而不是昵称——这就是逾期治理的社会压力机制本身。
录书 · 20 秒一本的流水线
这一页的性能指标是一本 20 秒——800 册按常规录法要 26 小时人工，这类项目八成死在这一步。
所以只有书名必填，架位和分类会记住不用重填，保存后自动拉起下一次扫码不打断。
ISBN 已存在会直接问「再加几册」，不重复建书目。
PHASE 1好用
目标是新人第一次打开，不用任何指导就能找到一本想看的书并借走。
找书
搜索完全在本地做：800 册缓存下来约 160KB，零网络延迟、可离线、支持拼音首字母
（图中输入「jg」命中「架构」）。唯一走网络的是「可借几册」——那个数实时会变不能缓存，
只查当前屏幕这一二十条。
书详情
回答三个问题：这是什么书 / 现在能不能借 / 不能借的话在谁手上。
藏本明细默认折叠——多数书只有一册，把「第几册」这层复杂度露给普通读者没有意义。
借书只说要哪本书、不指定哪一册，由服务端自己挑。
我的 · 含公开在借清单
第三个标签「大家在借」是逾期治理的主力：谁借了什么全员可见，
不需要任何人去执行，靠的是人不想被看见占着东西不还。
有意做成中性的「谁借了什么」——没做逾期排行榜，那是公开羞辱，
在同事之间会产生真实的怨气。
PHASE 2省心
目标是管理员一周花不到十分钟。理想状态是待办四个数字全是 0，扫一眼就能关掉。
管理台
核心是四个待办数字，全 0 时会显示「没有待办，这周不用管了」。
盘点、成员、设置、上报处理做成同页浮层而不是独立页面——
都是低频、进去做完就走的操作，为每个开一个页面只会让返回路径变长。
9:41●●● ▮
‹管理台
盘点✕
扫到312
系统里有309
在架但系统显示借出（5）
有人还了书没在系统里操作，一键确认即可
全部确认归还
扫到但系统里没有（3）
多半是有人捐书没登记，需要走录入
97871155460819787111641247
系统显示在架但没扫到（12）
可能插错架位。下次盘点还找不到再标丢失，别急着改状态
BC-000117BC-000238
盘点 · 结果三张单子
扫的过程中不弹任何确认框：扫一本震动一下、计数 +1、立刻拉起下一次扫码。
800 本要在半小时内扫完，每本多一次点击就是多十几分钟。重复扫会震两下但不重复计数。
「没扫到」那栏刻意不自动标丢失——书很可能只是插错了架位。
借阅管理 · 催还
催还按强度排序：公开清单 → 到期提醒 → 额度冻结 → 管理员私聊。
只有最后一步需要人，所以放这里，而且只给「复制文案去群里 @」，不做一键群发——
群发容易变骚扰，而多数逾期只是忘了，一条私聊就解决。
配色与字号
#c8a15a 主色
#b08d45 深金
#fdf8ef 浅金底
#f7f7f8 页面底
#ffffff 卡片
#4caf6d 可借
#e04f4f 逾期
#1a1a1a 主文字