Rednote H5
面向 /rednote/ 的浏览器入口，复用 h5/ 的页面、相机、检测、评分、报告及管理后台。不是小红书账号授权：同意隐私说明后由服务器生成随机浏览器身份，使用独立 HttpOnly Cookie 保存30天，可查看最近5份完整报告。清除浏览器数据、清除本机身份、身份到期或更换设备后无法恢复原身份；不同 App 的内置浏览器可能不共享身份。
本地样本环境
cd D:\juzi\rednote
npm ci
npm run dev
- 新入口：
http://127.0.0.1:18380/rednote/，后台/rednote/admin.html。 - 对照入口：
http://127.0.0.1:18380/state/，本地未配置微信真实授权，只提供原游客体验。 - 数据：
../temp/rednote-local-data/rednote/和state/，与真实 H5 数据隔离。 - 所有检测返回固定样本，不连接 Face++ 或淘宝／微信。后台在回环开发环境不要求 Basic Auth，公网必须使用部署模板的鉴权保护。
配置与隔离
真实服务直接运行共享 h5/server.js，不要运行 fixture-server 或 dev 脚本。新增 JUZI_ENTRY_MODE=rednote，并显式配置外部独立 JUZI_DATA_ROOT 及以 /rednote/ 结尾的 PUBLIC_BASE_URL。配置错误会在初始化账号／数据目录之前终止。部署模板另通过 JUZI_PROTECTED_DATA_ROOT 拦截旧数据路径（含符号链接），并将旧部署目录以只读方式挂载到新服务的运行环境；生产模式要求HTTPS。未设置入口模式时仍是原 state 模式。
- 原入口：
juzi_session，原有/state/Cookie 路径，微信和临时游客规则不变。 - 新入口：
juzi_rednote_session，/rednote/路径，服务器持久化浏览器身份；不会恢复微信 Cookie，也不会接受微信／淘宝登录接口。 - 账号身份和会话仅由服务器生成，客户端提交的 token、用户 ID、channel 不用来恢复身份或决定来源；服务器只保存会话 token 哈希。
- 表单缓存使用
juzi.rednote.profile.v1.*和juzi.rednote.auth.kind.v1，避免同域 localStorage 与 state 相互清理。 - 首次打开仅生成页面内体验状态，同意隐私后才创建服务器身份；有效 Cookie 自动恢复。清除本机身份会撤销服务端会话并清理本机档案缓存，界面明确说明历史不可恢复。
- 检测记录统一由服务端标记
channel=rednote。新实例后台及 CSV 可查看新来源，原实例数据和后台不改。 - 每个新实例同时只接纳1个主检测；上游主检测和侧脸请求使用有界串行队列。限流只约束新实例，不能代替旧入口和新入口共享 Face++ 账户的全局额度管理。
- 前台展示最近5份报告，后台检测记录及照片的保留方式沿用现有微信入口；没有删除或迁移原渠道数据。
验证
npm test
npm run test:browser
cd ..\taobao
npm test
npm run check:shared
npm run test:h5
新测试覆盖持久身份、首次同意、Secure Cookie、来源防伪、重启恢复、最近5份报告、越权拦截、侧脸缓存、并发限制，以及同一浏览器下 state/rednote 的登录、缓存、历史和退出隔离。浏览器截图位于 ../temp/rednote-browser/。自动测试使用样本，不代表手机相机已验收。
部署方式
已于2026-10-19发布到生产，版本 20261019-225927-4af825a。发布验证、备份位置及回退说明见 发布记录。
2026-10-19发布前基线：线上 juzi-h5.service 在127.0.0.1:8080运行，工作目录 /home/ubuntu/juzi/h5，版本 fc9f251；/state/ 正常，微信授权已启用。新入口使用独立目录、进程和数据存储。
部署到 /home/ubuntu/juzi-rednote/releases/<版本>/，current 仅指向新入口发布目录；数据固定 /home/ubuntu/juzi-rednote-data。不能在旧线上目录执行 git pull、覆盖其静态文件、移动旧数据或重启旧服务。
deploy/juzi-rednote.service 和 deploy/nginx-rednote.locations.conf 是部署模板，不会自动安装。管理员通过私有 /etc/juzi/rednote.env 配置 Face++ 凭据；不复制旧微信配置，也不将密钥放进仓库。
发布顺序：备份原Nginx配置并记录旧进程/版本/健康基线 → 部署新目录和独立数据 → 启动新服务并用8081检查 → 在现有HTTPS server中仅添加新location → nginx -t通过后平滑reload → 两入口健康、鉴权和数据隔离检查 → 用户手机验收相机及微信登录。
回退：还原新增前的Nginx配置、检查并reload，停止新服务；保留新入口数据供复核。无需重启旧服务，不删除或覆盖任何原数据。
共享主机、Nginx与Face++额度仍是公共依赖；生产发布记录应包含版本、配置备份位置及两入口验证结果。