私密的那一份，目录页上也得带锁 —

抓下来是一回事，摆出来是另一回事。每份豆列一页：简介、条目、豆瓣给的评分，以及用户自己写的评语。

评分和评语分开显示，不合成一行。合起来读的人分不出哪句话是自己写的—— 而这份站点上，「哪些字是你的」是唯一真正要紧的区分。评语走引用块。

条目的链接指向站外，这是刻意的：豆列条目的目标页 不在档案里（规范里写明了），所以不能套用 ../movie/123.md 那套站内相对路径——那会指向一个不存在的文件。

那把锁

豆列有私密的。私密豆列照常渲染（档案主人的决定：先都渲染出来），但标题前挂一把 🔒，正文顶上再说一句。

理由不是装饰。一份私密豆列渲染得跟公开的一模一样，等于把用户在豆瓣上明确做过的那个选择从档案里抹掉了—— 而这份站点是可以一键发到 GitHub Pages 的。

判据在 unknown 时也挂锁：连 <h1> 都没找到，说明抽取器可能坏了。把「不知道」显示成「公开」是这一档上唯一不可逆的错法。

第一版只在详情页挂锁，这是不够的：目录页恰恰是别人扫一眼的地方，而那一页上私密的和公开的画得一模一样。顺带把条目数也放进目录行—— 一份 45 条的和一份 1 条的，值得一眼看出来。

一份豆列真正可搜的只有两处：它的简介，和每个条目上的评语（实测 134 个条目里有 62 条）。条目的标题、简介、评分都是豆瓣的目录数据，而作品标题已经由标记那一档收过了。

在这儿再收一遍的后果很具体：同一个名字出来两条结果，其中一条点进去是「某份豆列」而不是那部作品。

所以是一条豆列一行，评语拼在一起。拆成一条条目一行会让 6 份豆列变成 134 行，把别的结果挤下去；而豆列页本来就不长，搜到「哪份豆列里写过这句话」，点进去就找得到。

一个字都没写过的豆列不进索引。 那份 25 条、全指向他人影评、0 条评语的纯书签夹里没有任何你的内容，标题从别处也找得到。实测 6 份进了 5 份。

实测搜「amazon上买了35USD」命中 2 条——豆列里的那条评语，和当年发的那条广播。同一件事在两处留了痕，两处都在档案里。

加豆列这一类记录的时候，我只改了 bin/generate.js。 bin/site.js 和 bin/deploy.js 各自还写着自己那份四行名单。

后果不是报错。缺的那一类被读成 []，生成器照常跑完， 只是少了几十页，而且一路绿灯。表现是：

npm run md      有豆列
npm run site    没有
npm run deploy  没有   ← 样张站就是用这条铺的

实测改完之后 deploy 的页数 4781 → 4789。

这个形状上一次出现是 SECTION_ORDER——同样一份清单抄在三个地方，加一个小节要同时改三处。区别是那次有测试钉着其中两处相等，所以漏改会红，那次就是这么被逮住的。这次那两处之间没有这样的测试。

改法是把名单挪进 src/canonical.js，三个入口都从那里取，新增一类记录只改一处；再钉一条测试：没有哪个入口可以自己再写 *.ndjson。钉的是「不许有第二份」，而不是「这三份要一样」—— 后者只在有人记得加第四处时才管用。

顺带修掉一处测试盲区：那条「模板引用的 front matter 键，生成器真的会写」的测试，是从固定几个页面构造器里扫的，而它漏了 doulistPage—— 于是豆列的新键一律被算成「模板引用了生成器不写的键」。 一份靠白名单枚举的检查，白名单本身没人检查。