server-ops/daily_2026-06-15.md

# 2026-06-15 工作日志

## Calibre-Web 电子书库部署

- Docker 部署 `linuxserver/calibre-web:latest`，端口 8083
- Caddy 反代 `books.xybkwd.top`（HTTPS 自动证书）
- nav 导航页新增"电子书库"卡片（琥珀色书籍图标，book SVG）
- 所有卡片状态统一为"运行中"
- 要闻页面字体再次加大（移动端摘要 18px，标题 19px）

## Gitea 仓库 ebook-library

- 通过 Gitea API 创建 `fxy/ebook-library` 仓库（fxy token: `513f4f51...`）
- 服务器 `~/ebook-library/` 初始化，目录结构：scripts/、docs/、config/
- README.md + .gitignore 已推送

## TIMELINE.md 修复

- TIMELINE.md 被 shell 转义弄乱，从 git 历史恢复原始内容后追加 Calibre-Web 条目

## DNS 发现

- `books.xybkwd.top` DNS 已解析到 43.163.225.30（可能是通配符或之前手动加的）
- 腾讯云 DNS API 密钥未找到（Lucky 配置加密、服务器/本地全面搜索无果）
- 如需 API 密钥自动化 DNS，需冯总提供腾讯云 SecretId/SecretKey

## 用户偏好确认

- 冯总明确要淡化"beast"称呼，新仓库用 `fxy` 组织，不使用 beast 命名

## 安全排查与加固

- 全面排查服务器安全状态：SSH 配置、防火墙、端口暴露、服务认证
- Lucky 已彻底删除（`/opt/lucky/` + Docker 残留全部清除）
- 发现 Caddy basicauth 全部缺失（之前设置后被取消）
- **已恢复**：gitea / dashboard / memo / nav / books 全部加上 basicauth（fxy / Qiyun2025!）
- 博客和 Vaultwarden 不加（博客公开，Vaultwarden 自身有登录）
- 验证通过：无密码返回 401，带密码返回 200
- 🔴 **安全铁律已固化**：严禁取消 basicauth，调试用 localhost 不改 Caddyfile
- 发现 Shadowsocks 服务在端口 31567（代理服务，正常）
- ufw 残留端口 16601（Lucky 残余）待清理，9001 待清理

## DeepSeek 余额显示修复

- 问题：两个 cron 脚本都在写 `/var/www/nav/data/balance.json`，每小时整点互相覆盖
  - `inspiration-collector/tools/deepseek_balance.py` — 扁平格式，JS 可读 ✅
  - `ai-chat/fetch_balance.py` — API 原始格式（`balance_infos` 嵌套），JS 解析失败 ❌
- 修复：删除 `ai-chat/fetch_balance.py` 的 cron，只保留格式正确的那个
- 立即重跑脚本，余额恢复显示 ¥7.58

## 栖云个人服务部署方案 v2

- 生成完整方案文档（`栖云个人服务部署方案_v2.md`），覆盖 8 个方向：
  1. 全文搜索（Meilisearch）
  2. 书影音管理（Ryot + Calibre-Web）
  3. n8n 自动化（资源较重，建议后置）
  4. RSS Hub + Miniflux
  5. 图床（Lsky Pro）
  6. 自动化抓取（changedetection.io + Python 爬虫）
  7. 语音助手（极简 Web 方案）
  8. 微信读书同步（weread-exporter）
- 资源预算：全部部署内存 +950MB，磁盘 +1.35GB，当前可用 1.5G/45G，可行但偏紧
- 建议分三批推进，P0 优先：微信读书同步 + 图床 + 全文搜索

## Memos 同步修复

- 问题：手机 App 同步不了，报"未能读取数据，格式不正确"
- 原因：Caddy basicauth 拦截了 Memos API 请求，App 无法通过 basicauth 认证
- 修复：memo.xybkwd.top 去掉 basicauth（Memos 自身有用户登录系统）
- 更新安全铁律：Memos 和 Vaultwarden 不加 basicauth，自身有认证

## Memos API 调用踩坑记录（重要经验，已固化到 MEMORY.md）

- **协议**：Memos 用 Connect RPC（POST + JSON），不是 RESTful GET
- **接口**：`POST /memos.api.v1.MemoService/ListMemos`
- **字段名**：时间字段是 `createTime`（不是 `createdTime`/`created_at`），内容字段是 `content`
- **外网不可调**：Caddy 反代 `memo.xybkwd.top` 无法正常转发 RPC 请求，必须 SSH 到服务器走 `localhost:5230`
- **认证**：Bearer token，存在服务器 `secrets/secrets.json` 的 `memos_token` 字段
- **本次踩坑**：先用外网 REST 尝试（404）→ 再试 v1 路径（404）→ 最终通过 SSH localhost + Python requests 才成功提取数据

## 海康威视参观学习

- 冯总作为"90后四级副职培训班"学员（单位组织，浙大培训）参观海康威视总部
- 核心洞察：海康真正厉害的不是图像技术，而是3万SKU的生产排程和供应链管理能力
- 生成经历：v1（凭对话记忆，要点不全）→ 用户要求查 Memos → v3（基于真实 Memos，2101字）→ v4（修正身份为培训班学员，不限篇幅，4260字）
- **教训：生成课程/参观总结前，必须先从 Memos 提取真实记录，不能仅凭对话上下文编造；必须确认用户身份**
- 已推送 Gitea：`inspiration-collector/ai-insights/daily/2026-06-15/`
- 手动总结流程已固化到 MEMORY.md（Memos提取→本地生成→SCP上传→Git推送→附件发送）

## 灵感收集器标签功能改造

- 改造了 `daily_digest.py` 和 `memos_client.py`，让标签在 AI 分析中真正发挥作用
- **改动内容**：
  1. AI 提示词新增标签说明段落（标签揭示场景、延续性、主题聚类）
  2. memo 按标签分组展示（同主题归在一起，方便 AI 融会贯通）
  3. frontmatter 自动记录当天出现的所有用户标签
  4. 跨日标签延续检测（如果今天和昨天共享某标签，提醒 AI 关注连续性）
  5. 新增 `list_memos_by_tag()` 方法（支持按标签跨日检索）
  6. 新增 `aggregate_tags()` + `group_memos_by_tag()` 工具方法
- 篇幅规则更新：除"简要分析"限 2000 字外，其余不设上限
- 测试通过：8 条 memos，标签 `90后四级副职培训班`/`浙江` 正确识别并传入 AI
- 已推送 Gitea：commit `75586f1`

## 灵感收集器标准话术库

- 盘点了灵感收集器全部功能（10 大模块：标签、每日分析、课程总结、周报、待办、新闻、余额、文库、运维、组合指令）
- 生成了标准话术库文档（`灵感收集器标准话术库.md`），每句话术对应一个已实现的功能
- 覆盖 cron 自动运行和手动触发两种场景

## 自动任务文档

- 生成 `docs/自动任务一览.md`，记录服务器全部 14 条 cron + 6 个 systemd/Docker 服务
- 包含数据流向图，梳理各任务间的依赖关系
- 已推送 Gitea：commit `36a507e`
- 更新机制：每次 cron 变更必须同步更新该文件

## 每日要闻扩展栏目

- 新增 4 个栏目：政策速递、AI/量化前沿、市场行情、深度解读
- **新增 6 个 Python 脚本**：
  - `fetch_policy.py` / `summarize_policy.py` — 政策 RSS + AI 摘要
  - `fetch_research.py` / `summarize_research.py` — ArXiv AI/量化博客 RSS + AI 分类摘要
  - `fetch_market.py` — A股指数（东方财富 API）+ 加密货币（CoinGecko API）
  - `deep_dive.py` — 从要闻 Top1 选取，DeepSeek 生成 800-1200 字深度分析
- **新增 6 条 cron**：政策/研究每6h抓取+摘要，市场每1h，深度解读每天22:35
- **改造 brief.html**：新增市场行情顶栏（红涨绿跌）、sidebar 合并所有栏目、深度解读卡片置顶、5 分钟自动刷新
- **数据流**：6 个 RSS 源 → 原始 JSON → AI 摘要 JSON → brief.html 并行加载
- 测试结果：政策15条、研究37条（3分类）、市场8条、深度解读1条（美伊停火分析）
- 自动任务文档更新至 v1.1
- 已推送 Gitea：commit `f31c741` + `0da3fc7`

## 每日要闻 UI 修复（12:42~12:50）

### 问题 1：市场行情顶栏太丑
- 原版：单行水平滚动，A股和加密货币混在一起，排列混乱
- 修复：改为双行布局（A股一行、加密一行），每个指数/币种用 chip 卡片样式（带边框、圆角、背景），方向符号 ▲▼ 配色区分（红涨绿跌）

### 问题 2：所有分类栏目显示的都是深度解读
- 原因：深度解读卡片是独立的 `deepDiveContainer`，放在所有 cat-section 之外，但 sidebar 没有深度解读的独立 tab，只有第一个新闻分类 tab 是 active 的
- 修复：深度解读作为独立的 sidebar tab（排在第一位），点击只展示深度解读内容；其余 tab 各自对应自己的新闻分类。switchTab 改用 `data-tab` 属性匹配

### 问题 3：ETH 行情"不见"（实际是 change_pct 显示重复）
- 根因：`fetch_market.py` 输出 `change_pct: "▲ 2.26%"`（含方向符号），前端 `renderMarket` 又自行追加了一个 `chg-icon ▲`，导致显示为 `▲ ▲ 2.26%`，视觉上很乱
- 修复：后端 `change_pct` 改为纯数值 `"2.26%"`，方向由 `is_up` 布尔值控制，前端统一渲染方向符号
- 附加：A股东方财富 API timeout 从 10s 提高到 15s，减少超时失败（东京服务器到国内 API 延迟不稳定）
- 已推送 Gitea：commit `e3a18a2` + `d86bede`

### 经验固化：前后端数据契约
- **铁律**：JSON 数据输出纯数值/布尔值，不包含渲染相关的装饰符号（▲▼ 箭头、$ 货币符号等尽量少）
- 方向/颜色/图标等展示逻辑统一由前端处理，避免前后端重复导致显示混乱
- A 股行情接口 timeout 需 ≥15s（东京→国内 API 链路不稳定）

## 新闻发布时间 pub_time 功能（14:30~14:50）

### 需求
- 冯总要求新闻卡片显示发布时间，判断新闻即时性

### 实现方案：后端回填 + 前端展示
- **后端**：RSS 原始数据已有 `published` 字段，但 AI 摘要脚本输出 JSON 时未保留
- **方案**：AI 摘要输出后，用原始 RSS 的 `published` 按**标题精确匹配 + 前20字符模糊匹配**回填 `pub_time`
- **时间格式**：当天显示 `HH:MM`，非当天显示 `MM-DD HH:MM`
- **匹配率**：news 96/102 (94%)、policy 8/15 (53%)、research 33/37 (89%)
- **依赖**：`python3-dateutil` 的 `dateutil.parser.parse()` 解析各种 RSS 时间格式

### 修改文件
- `summarize_news.py` v2：新增 `build_time_lookup()` + `match_pub_time()`，AI 提示要求保留原标题（匹配关键）
- `summarize_policy.py` v2：同上
- `summarize_research.py` v2：同上
- `brief.html`：新闻卡片 badge 行（`.badge`）改为 flex 布局，右侧显示 `.pub-time`
- `backfill_pubtime.py`：一次性脚本，给已有数据补填 pub_time
- 已推送 Gitea：commit `eda0534`

## 诸暨枫桥经验学习考察总结（15:34）
- 从 Memos 提取原始记录（1条 memo），用 DeepSeek API 生成课程分析（2148字/7分钟阅读）
- 内容：枫桥经验陈列馆参观 + 枫源村老书记骆根土座谈
- 关键概念已补充背景：枫桥经验历史、千万工程、四前工作法、四先四早、枫桥三贤等
- 已推送 Gitea：commit `8ab1b3c`

## 🔴 模型选择铁律（14:47 冯总严令，18:48 补充界限）
- 智能体使用冯总积分时只准用 DeepSeek v4，任何步骤不得切换到其他模型
- 禁止智能体调用 GLM 模型（任何 GLM 系列均禁用）
- **补充**：冯总自行购买的 API Key 由冯总自由切换，不在本禁止之列

## 手动日报触发 & 对比验证（16:01）
- 手动触发 daily_digest.py，生成今日日报（2916字/4条灵感），含海康+枫桥+数字基建
- 与课程总结（诸暨枫桥，2148字）对比：日报=思考输出（融会贯通），课程总结=知识存档（结构化笔记），互补关系
- 冯总满意两份文档，确认保留

## 冯总对写作体系的规划（16:07 确认）
- **日报**：保持每天 22:30 cron 自动执行（当前培训期主要分析学习内容，后续加入工作事务）
- **课程总结/参观总结**：手动触发，不设 cron（冯总自己决定什么时候生成）
- **写作体系方向**：后续会开发多种写作模板，对文库、灵感库进行更多维度的发掘、梳理、分析和写作
- 本质上冯总在构建一个"个人知识管理 + 多维度写作输出"体系，灵感收集器是其中的核心引擎

## 待办推送修复（16:21）
- 问题：`extract_todos.py` 的 cron 每 30 分钟跑一次，但今天日报的待办没有推送到待办系统
- 根因（双重）：
  1. AI 输出格式变了：从 `[ ] checkbox` 变成 `1. **粗体**：描述`，正则不匹配
  2. digest 文件路径变了：从 `daily/YYYY-MM-DD_digest.md` 变成 `daily/YYYY-MM-DD/YYYY-MM-DD_digest_HHMMSS.md`，脚本没递归子目录
- 修复：`extract_todos.py` 升级为递归搜索 + 多格式匹配 + 模板标题过滤
- 已手动清理 4 条误推的模板标题（【今日输入】等）
- 测试结果：8 条待办提取成功，4 条有效待办推送到 API
- 已推送 Gitea：commit `1a3a211`

## 第四小组政绩观学习研讨报告（17:00）

- 冯总要求以第四小组名义撰写《关于习近平总书记地方工作期间坚持正确政绩观生动实践》学习研讨报告
- 素材来源：Memos 全部培训记录（浙大3天课程）+ 诸暨枫桥经验学习总结 + 海康威视参观总结 + 权威资料（求是网、央广网、中工网等）
- 报告约4200字，四个部分：①政绩观核心要义 ②五个维度分析（战略定力/改革创新/为民情怀/担当作为/全面发展） ③第四小组学习收获 ④结语
- 贴合课程实际：枫桥经验、千万工程、八八战略、海康威视参观、科大讯飞参观、宇树科技讲座、数字浙江课程、章丰AI课程均有引用
- 已推送 Gitea：commit `79f166b`
- Word+PDF生成：python-docx + Word COM接口，符合公文格式（GB/T 9704-2012），标题和第四小组居中

## Auto 模式 token 消耗排查（18:36~18:45）

- 冯总报告过去2小时 token 消耗巨大，要求排查
- 排查路径：DB 逐表查询 → trace 文件分析 → 会话消耗对比
- **我的错误**：仅凭 sessions 表的 model 字段就下结论说"auto 选了大模型"，没有核实实际调用的模型
- **事实**（冯总去网页端对账后确认）：1600+ 积分全烧在 **GLM 5.0 Turbo** 上，该模型当天 14:47 已被冯总明令禁止使用
- DB 里 session 标记为 `deepseek-v4-flash`，实际走的却是 GLM → sessions.model 字段不可信
- 教训已写入跨项目用户级 MEMORY.md：只信平台账单/API 日志，不信 DB 字段
- 冯总明确了模型使用界限：自己的 API Key 自由切换，我使用积分时只能用 DeepSeek

## 导航页重复登录修复 — Cookie Session Auth（19:00~19:05）

- **问题**：Caddy basicauth 导致浏览器每 ~1 小时要求重新输入密码，尤其是移动端。用户每天登无数遍，痛点明显
- **根因**：HTTP Basic Auth 依赖浏览器缓存凭据，移动浏览器缓存策略不稳定，且跨子域不共享凭据
- **方案**：用 Python auth_proxy（port 9002）替换 Caddy basicauth，改用 Session Cookie（7 天过期，HttpOnly, SameSite=Lax）
- **架构**：
  - Caddy → auth_proxy:9002 → 验证 session cookie → 代理到实际后端或提供静态文件
  - 无 cookie → 302 重定向到 `auth.xybkwd.top/login?redirect=...`
  - 登录后 Set-Cookie，7 天有效，跨子域共享
- **部署内容**：
  - `/home/ubuntu/auth_proxy.py` — Python HTTPServer，bcrypt 验证密码，HMAC-SHA256 签名 token
  - `/etc/systemd/system/auth_proxy.service` — systemd 服务，开机自启
  - `/etc/caddy/Caddyfile` — 去掉所有 basicauth，改用 `reverse_proxy localhost:9002`
  - 新增 `auth.xybkwd.top` → 代理到 auth_proxy（登录页面，无额外认证）
- **测试结果**：
  - auth.xybkwd.top/login → 200，登录页面正常渲染
  - nav.xybkwd.top（无 cookie）→ 302 跳转到 auth.xybkwd.top/login?redirect=...
  - POST 登录（正确密码）→ 302 + Set-Cookie（7天）
  - 带 cookie 访问 nav → 200，35KB index.html 正常加载
  - 带 cookie 访问 dashboard → 200，48KB 仪表盘正常
  - 带 cookie 访问 gitea → 200，13KB gitea 正常
- **安全性不降低**：bcrypt 密码验证不变，cookie HttpOnly 防 XSS，HMAC-SHA256 签名防篡改
- **服务恢复正常**：blog/vaultwarden/memo 不受影响（没有经过 auth_proxy）

## auth_proxy 调试 — Cookie 跨子域修复（19:18~19:28）

- **现象**：用户报告"登录以后直接不跳转了"——带 cookie 访问各子域仍被 302 回登录页
- **根因1（Cookie 跨子域失效）**：Set-Cookie 没有 `Domain=.xybkwd.top`，浏览器只为 `auth.xybkwd.top` 存 cookie，访问 `nav.xybkwd.top` 时不带 cookie
  - 修复：`cookie_val` 加 `Domain=.xybkwd.top;`
- **根因2（语法错误导致服务崩溃）**：用 SSH heredoc 直接 patch Python 代码，导致 `unterminated string literal`，auth_proxy 反复 crash/重启
  - 修复：本地 `py_compile` 验证语法 → SCP 上传，不再用 heredoc 写 Python
- **根因3（Set-Cookie 值带多余引号）**：`format()` 里用了中文引号 `""`，导致 `sess="token..."` 而不是 `sess=token...`，浏览器拒绝该 cookie
  - 修复：`sed -i` 去掉多余引号，验证 `Set-Cookie: sess=eyJ...`（无引号）
- **根因4（多轮 hotfix 弄坏代码）**：多次 heredoc patch 叠加，最终 `verify_token` 中 `SECRET_KEY` 引用错乱
  - 修复：本地重写完整 `auth_proxy_v2.py`，语法验证通过，一次性 SCP 覆盖
- **最终验证**（curl 完整链路）：
  1. POST `/login` → 302 + `Set-Cookie: sess=...; Domain=.xybkwd.top; Max-Age=604800`
  2. 带 cookie 访问 `/` → 200，返回 35KB index.html
  3. 带 cookie 访问 `/api/todos` → 200，返回 JSON
- **经验**：
  - 🔴 **禁止用 heredoc 写 Python 到服务器**：SSH 转义规则复杂，极易引入不可见错误。正确流程：本地写 → `py_compile` 验证 → SCP 上传 → 重启
  - Cookie 跨子域必须显式设 `Domain=.example.com`，否则浏览器按当前域名限制
  - `Set-Cookie` 的 token 值不要加引号，RFC 6265 不允许
  - 调试代理服务：用 `curl -D /tmp/hdr.txt -H "Cookie: sess=..." http://localhost:9002/...` 逐层验证
- 已推送 Gitea：commit `pending`

## auth_proxy 事故 — Caddy 回滚（19:34~19:57）

### 事故经过
- 19:34 冯总报告：brief/dashboard/gitea 三服务同时"坏了"
- 根本原因：auth_proxy 替换了 Caddy 的反向代理层，但 auth_proxy 代理能力不完整
  - Gitea Web/API 请求被 auth_proxy 拦截后无法正常工作
  - dashboard /api/market-structure 等路径返回 404
  - brief 的静态文件被 auth_proxy 的 serve_static 错误处理

### 回滚操作
1. 恢复 Caddyfile：所有服务直接 reverse_proxy 到各自后端端口
2. 保留 auth.xybkwd.top → localhost:9002（auth_proxy 仅作登录门户）
3. 当前状态：所有服务 200 正常 ✅

### basicauth 恢复失败
- 尝试恢复 basicauth 但 Caddy v2.11 的 hash 格式不兼容
- Caddy v2.11 `basic_auth bcrypt` 要求的 hash 格式与 `caddy hash-password` 输出不一致
- $`$` 符号在 Caddyfile 中可能被解释为环境变量
- 临时方案：无 auth 开放访问（安全缺口待修复）

### 🔴 铁律：Git-First 部署原则（冯总19:57确认）
- **所有配置变更必须先 commit 到 git 仓库，再部署到生产环境**
- 事故中幸亏能从 git 历史（commit 6c35f31）找回正确的 Caddyfile 版本，否则回滚将极为困难
- 本次教训：auth_proxy 调试过程中直接修改了 /etc/caddy/Caddyfile 和 /home/ubuntu/auth_proxy.py，未及时 git commit，这是一种危险的运维习惯
- **行动计划**：未来任何生产环境变更，必须：
  1. 先在 git 仓库修改并 commit
  2. 再从 git 部署到生产
  3. 回滚时直接从 git checkout
- 更严格的版本：可以建立 /etc/caddy/ 的 git 仓库，与 Gitea 同步

### 已推送 Gitea
- `fxy/nav-page` commit `41f8ded` — rollback Caddyfile 到直接代理
- `beast/server-ops` commit `438245a` — CHANGELOG v1.2.0 + 铁律记录

## 双认证方案上线（20:00~20:08）

- **架构**：Caddy @authed cookie 匹配 + basic_auth bcrypt 兜底
  - 有 `sess` cookie → 直接放行（7天免登录）
  - 无 cookie → basicauth 要求用户名密码
  - auth.xybkwd.top/login → auth_proxy 签发 cookie（Domain=.xybkwd.top）
- 测试全部 7/7 通过 ✅
- 已推送 Gitea：`fxy/nav-page` commit `a86991a`

## 🏆 里程碑 V1 达成（20:33）

- 冯总确认：所有服务正常，认证架构按预期运行
- 认证架构定型：Cookie 免登录（7天）+ 统一登录门户 auth.xybkwd.top
- 完整快照已固化到 MEMORY.md 第 9 章「里程碑 V1」
- 核心文件均已 git commit，可秒级回滚
- Gitea 仓库最新 commit：
  - `fxy/nav-page` `1a80249` — Caddyfile（Cookie 路由 + 反代）
  - `beast/server-ops` `a6e85c6` — auth_proxy + milestone_v1.md

## Calibre-Web 配置踩坑（20:35~21:30）

### 问题1：上传后卡死、加载慢
- **根因**：用宿主机 `calibre 7.6` 的 `calibredb` 创建 metadata.db，版本与 Calibre-Web 容器内库不兼容
- **修复**：清空书库，让 Calibre-Web 自己创建数据库

### 问题2：路径无效"DB Location is not Valid"
- **根因**：`check_valid_db()` 函数要求 metadata.db 必须存在且有 `library_id` 表
- **修复**：手动用 sqlite3 创建包含 `library_id` 的空数据库

### 问题3：上传报错 "no such column: publishers.sort"
- **根因**：手动创建的 metadata.db 表结构不完整，缺少 `publishers.sort` 等列
- **修复**：用 `calibredb add` 创建完整规范的 metadata.db（397KB vs 手动82KB）

### 问题4：配置保存后仍 redirect 到 dbconfig
- **根因**：settings 表中 `config_calibre_uuid` 与 metadata.db 的 `library_id.uuid` 不匹配
- **修复**：更新 settings.config_calibre_uuid 匹配 metadata.db.library_id.uuid

### 最终状态
- 中文界面 ✅ | 上传功能开启 ✅ | 站点标题"栖云书库" ✅
- 书库已有《道德经》1本，上传功能正常 ✅
- 数据库用 calibredb 创建，schema 完整，后续不再报错
- 关键经验：Calibre-Web 的 metadata.db 必须用 calibredb 或 Calibre-Web 自身创建，不能手动 sqlite3

## 微信读书笔记同步脚本（21:40~23:00）

### 部署
- 脚本路径：`~/weread-sync/sync.py`
- API Key：`~/.keys/weread_api_key`
- 仓库：`gitea.xybkwd.top/fxy/weread-notes`
- Cron：每4小时同步一次（crontab `0 */4 * * *`）

### 修复：书评/想法未导出
- **根因1**：API 参数名大小写错误——脚本传 `bookId`（驼峰），API 期望 `bookid`（全小写）
  - 修复：`bookId=book_id` → `bookid=book_id`
- **根因2**：数据结构嵌套——书评内容在 `review.content`，不是直接 `content`
  - 修复：`r.get("review", {}).get("content")`
  - 原脚本直接 `r.get("content")` 永远为空

### 修复：文件名带数字后缀
- 原脚本文件名格式：`{safe_title}_{bookId}.md`，bookId 无意义
- 修复：改为 `{safe_title}.md`，bookId 不在文件名中出现

### 修复：书评与原文分离
- 原格式：只有想法内容（看不出来在说什么）
- 新格式：原文用 blockquote `>`，想法紧随其后，一目了然
  ```
  > 原文内容
  >
  > 我的想法
  > [时间戳]
  ```
- 按章节分组，空章节名不渲染标题

### 结果
- 2837 条划线 + 226 条想法 ✅ 全部正常导出
- 文件名：`遥远的救世主.md`（不再有数字）
- 无需额外权限，纯 API 调用完成

## 收尾：认证可靠性修复（23:05~23:15）

### 问题1：有的设备频繁要密码
- **根因**：Set-Cookie 缺少 `Secure` 标志
- 浏览器看到 HTTPS 连接（经 Caddy 终止 TLS），但 cookie 无 `Secure` 标志
- 移动端浏览器（尤其 Safari/Chrome iOS）可能将无 Secure 的 cookie 视为 session-only，关闭页面即丢失
- **修复**：`cookie_val` 加入 `Secure;`
- 注意：虽然 Caddy → auth_proxy 是内部 HTTP，但浏览器看到的是 HTTPS，所以 `Secure` 标志是必要的

### 问题2：有的设备点进去页面不见
- **根因**：Caddy 的 `header Cookie "sess=*"` glob 匹配只匹配 header **开头**
- 当浏览器累积了多个 `.xybkwd.top` 的 cookie（如 Gitea session、其他服务 token），`sess=` 不在 header 最前面时，匹配失败
- Caddy 认为"无 cookie" → 302 到登录页 → 但实际有 cookie → 循环/白页
- **修复**：`sess=*` → `*sess=*`（通配符前置，匹配 header 中任意位置）

### 测试全部通过
```
1. 仅 sess cookie → 200 ✅
2. sess 在中间（其他 cookie 前后夹击）→ 200 ✅
3. 无 cookie → 302 ✅
4. 登录 → 302 ✅
5. 带 cookie 访问 → 200 ✅
```

### 已推送 Gitea
- `fxy/nav-page` commit `eefe9ac` — Caddyfile `sess=*` → `*sess=*`
- `beast/server-ops` commit `65d28af` — auth_proxy 加 `Secure` 标志