Legado 大源工程化：jsLib 模块化与 build.mjs 装配

jsLib 上千字符、多模式、需要迭代交付的源，不要再直接编辑大 JSON。项目化管理它。

什么时候需要工程化

• jsLib 超过 1000 字符；
• 同一源有多模式（线路切换/分类分支）；
• 你已经在同一处第三次手滑改错；
• 需要交付给别人长期维护。

简单源（百行以内、单模式）直接写没问题——工程化是有成本的，别过度。

目录结构

text
work/{书源名}/
├── src/
│   ├── jslib/       # 公共函数库（按功能分模块文件）
│   ├── loginUrl/    # 登录脚本
│   ├── loginUi/     # 登录界面配置
│   ├── explore/     # 发现页规则
│   ├── searchUrl/   # 搜索规则
│   └── rules/       # 搜索/详情/目录/正文规则
├── build.mjs        # 装配脚本
├── masters/         # 权威母版（只读，不直接改）
│   └── versions/    # 母版历史归档
└── dist/            # 产物输出

装配脚本做什么

1. 确定性构建：五环节薄规则各 6-13 行，逻辑全在模块里；同样输入永远产出同样 JSON。
2. 语法门禁：build 时对每个 JS 片段跑 node --check，语法错误在构建期拦截——而不是真机白屏才发现。
3. 产物校验：装配后跑结构断言（必备字段齐全、无孤儿引用），失败即中止。

版本纪律

• 改前对母版做哈希比对归档；改后 dist 输出两份：ASCII 文件名 + 中文文件名，并过静态校验。
• 母版可能落后于用户手上版本（用户可能在 App 里改过）——以上传件为基底，禁止直接用母版生成成品。
• 变更日志三行式：改了什么 / 为什么 / 验证到第几级。

五环节拆分原则

• jslib：纯函数、无状态、可单测；不引用其它环节的变量。
• loginUrl/loginUi：只管凭据收集与面板交互；不掺业务规则。
• explore/searchUrl/rules：薄壳，每段只做「参数 → 调用 jslib → 映射结果」。
• 环节间通过明确的数据结构传值，不共享全局变量。

这套约束的价值在大源迭代时爆发：改一个模块只影响一个文件，构建门禁保证不会把半成品发出去。