2.1.8

2.1.8

本版以修复与可诊断性为主，另含一项随机页体验改进。桌面端与 Android 端均包含（Android 见文末）。

安全

• #14 内存中的会话凭据：所有 Windows 启动器（run.bat / jmnext.bat / NSIS 启动项，共 7 处）默认加
  -XX:+DisableAttachMechanism，切断 jcmd GC.heap_dump 这类"附加进程导堆再扫内存"的路径。
  代价：同时禁用 attach 类诊断工具；需要诊断时可由用户自行去掉该参数。
  如实说明：只要攻击者能以同一用户身份附加到 JVM，内存仍然可读 —— 这条是提高成本，不是杜绝。
  也没有做"进程内加密 token"：解密密钥同在一个进程里，攻击者 dump 一次同样拿到密钥与明文，那是安全表演。
  详见 desktop/SECURITY.md 的威胁模型。
• #12 本地凭据存储：
  • 密钥文件权限收紧（POSIX 等价 chmod 600；Windows 用 java.nio 的 ACL 移除 Users /
    Authenticated Users / Everyone 等宽泛主体，因为 File.setReadable 在 Windows 上只是只读属性、不设 ACL）；
  • 新增可选口令保护密钥（PBKDF2-HMAC-SHA256 12 万次派生 + AES-GCM 包裹，纯 JDK 无原生依赖）：
    全新安装默认开启（首次启动弹一次说明，可拒绝且不再打扰），老安装保持原状，
    可用 JMNEXT_KEY_PASSPHRASE_ENABLE=0 强制关闭；口令错误时 fail closed，不退化成明文存储；
  • 登出/清凭据时销毁密钥材料（此前只清键值存储，密钥文件仍留在磁盘上）；
  • 新增威胁模型文档，写清"防住了什么、防不住什么"。
    未验证：Windows 上的 ACL 与注册表实际表现（开发环境无 Windows，文档里给了 icacls 自查命令）。
• #11 偏好节点改名：com/jmcomic_next → com/jmnext；旧节点只读保留并在首次读取时迁移到新节点；
  clear() 同时清旧节点 —— 否则登出后旧密文会被回落逻辑"复活"，等于没清掉本地令牌。

修复

• #7「x64 的 exe 打开后没有文字」：Windows 各包不再强制 JMCOMIC_RENDER=GL，回到应用自己的软件渲染默认。
  依据：报告者实测（把该变量改回软件渲染后文字正常），且日志中反复出现
  org.jetbrains.skiko.RenderException: Failed to choose DirectX12 adapter. —— 该机器选不出 DirectX12 适配器，
  强制 GPU 必然渲染初始化失败。GPU 改为显式选择，并在日志中写明"若窗口没有出现或内容全黑，
  去掉该环境变量即可回退软件渲染"。

可诊断性与日志

• #9 启动环境摘要：启动即打印一行
  应用版本 | 系统与内核 | 架构 | 运行时(Java 版本与厂商) | 图形后端 | 字体；
  字体段会明确报出是否命中常见中文字体（雅黑/宋体/黑体/Noto Sans CJK SC/Source Han Sans SC/文泉驿等）
  并给出前 6 个字体族样例 —— 排查 #7 时最缺的就是这条信息。
• #9 崩溃信息：未捕获异常时先打印多行环境块，再打堆栈。
• #9 噪声治理：图片下载失败按（类型 + 异常类名）聚合、HTTP 错误码按状态码聚合（首次全量，之后每 50 次汇总一条）；
  每页预取与图片解码细节降为 debug 级，JMNEXT_VERBOSE=1 或 -Djmnext.verbose=true 可恢复；
  用户动作与关键结果（登录成功、发表成功等）保持原样，不会被吞掉。
  参考：2.1.7 的一份 1342 行日志里有 895 行是重复的同一类下载失败。

体验

• #13「随机漫画」：从"随机"进入的详情页新增 「换一个」 按钮，点击后原地重新随机（替换详情内容，
  滚动回到顶部），不必退回随机页再点一次；从首页/搜索/收藏/分类进入的详情页不显示该按钮
  （用来源 id 判断，不影响其它入口）。
  未验证：本机无图形环境，Compose 界面起不来，交互需在真机确认；按钮当前位于详情页顶部，
  位置与样式可按你的偏好调整。

其它

• 版本号三处一致：Version.kt 回退常量、desktop/build.gradle.kts 的 packageVersion 与
  Implementation-version 均为 2.1.8（DESKTOP_VERSION 优先读 jar 清单，只改常量会导致包自称旧版本）。
• 本版包含 Android 包：Android-full-2.1.8.apk 与 Android-lite-2.1.8.apk（versionCode 42）。

---

本版包含 Android 包：Android-full-2.1.8.apk 与 Android-lite-2.1.8.apk（versionCode 42）。

2.1.7 — 修复 issue #5（更新入口给出正确的下载直链）

2.1.7 — 修复 issue #5：更新入口给出正确的下载直链

问题修复：更新检查一直是对的，坏在只给了一个「打开发布页」按钮，而发布页的 Android 附件名（Android-full-<版本>.apk）不含架构 —— 一个包同时支持 arm64 与 x86_64，但名字上看不出来，arm64 用户按「arm64 版」去找自然找不到。现在由应用算出该下哪个包并给直链（Android 按 full/lite 变体，桌面按系统与架构且统一包排第一）。另附 issue #6 的热更新工具链评估：严格热更新不可行，本版做到的是「一键更新」。

问题修复（issue #5）：更新入口给不出可用的下载。

根因

更新检查本身是好的（读 releases/latest 的 tag_name、与本地版本比较、弹一句"有新版本"），
但它只给了一个**「打开发布页」**按钮。而发布页上的 Android 附件名是 Android-full-<版本>.apk ——
名字里没有架构（一个包同时含 arm64 与 x86_64 的 native 库）。于是 arm64 用户被告知有新版本后，
到发布页按"arm64 版"去找，找不到任何带 arm64 字样的文件，表现就是"总是获取不到更新包"。

修法：由应用算出该下哪个包，并给直链

• 共享层 UpdateCheck 新增四个纯函数（都有单元测试）：版本归一化、tag 规范化、按变体算 Android 附件名、
  按系统与架构算桌面附件名、以及 release 附件直链。命名与发布脚本严格对应，将来改命名规则测试会立刻失败；
• Android：发现新版本时多一个「下载更新包（Android-full-x.y.z.apk）」按钮，按 BuildConfig.APPLICATION_ID
  自动选 full 还是 lite；并写明"一个安装包同时支持 arm64 与 x86_64，无需区分架构"；发布页保留为兜底；
• 桌面：同样按 os.name/os.arch 给候选直链，统一包排第一并标注"推荐"（内含两套运行时、自动按架构选择），
  另给对应架构的 ZIP / tar.gz 作为备选。

关于 issue #6 的"热更新"（结论：严格意义做不到）

端	可行的	不可行的
Android	一键下载 + 拉起系统安装（用户点一次确认，Android 8 起无法静默）	运行中换逻辑。需要 Tinker（停更）/Robust（现存的真热修复）/Sophix（已停服）这类框架 + 基线 APK 与补丁包管理；官方 Play 路线（Play Core 应用内更新）要求走 Google Play，而我们发 GitHub Releases
桌面	一键下载 + 退出后替换 + 重启（或 update4j 这类自更新库）	运行中换逻辑。JVM Instrumentation 只能改已有方法体，真类结构替换要 JRebel（商业）或 DCEVM（改过的 JDK，需随包分发）

本版做到的是"一键更新"：应用内直接给出正确包的直链，用户点一下就开始下载。
未验证：更新按钮点击后的实际效果（是否真的下载到正确文件）需要用户在真机上确认 —— 我这边只能验证编译与链接拼接逻辑。

2.1.6 — 汉字显示修复 + 架构自适应统一包（Windows exe / Linux tar.gz）

2.1.6 — 汉字显示修复 + 架构自适应统一包

两项新工作：①桌面端汉字显示（显式选含中日韩字形的系统字体族并应用到全部排版样式；I/O 编码钉成 UTF-8）；②架构自适应统一包（Windows 单体 exe 与 Linux tar.gz 各一个，内含两套运行时自动选择）。原有的按架构包全部保留，本版共 16 个附件。

两项新工作：桌面端汉字显示、以及"不用分辨架构"的统一包。

一、汉字显示（Windows 上乱码/方框）

原因：两端都没打包字体，桌面端用 FontFamily.Default —— 它在 Windows 上等于 Segoe UI（不含汉字），
于是 fallback 要么找不到字形（方框/问号），要么落到日文字体上（汉字按日式写法渲染）。

修法两条：

1. 显式选一个含中日韩字形的系统字体族：按平台给候选链（Windows 优先微软雅黑，Linux 用 Noto Sans CJK/思源/文泉驿，
   macOS 用苹方），用 Skiko 的 FontMgr 按字体名查系统字体，取第一个能加载的；应用到全部排版样式
   （此前只定制了 4 个样式，其余会退回默认字体、汉字同样出问题）。取不到候选就退回默认，不比现在差。
2. I/O 编码钉死为 UTF-8（file.encoding、sun.stdout.encoding、sun.stderr.encoding）：
   Windows 控制台默认 GBK，日志 %USERPROFILE%\jmnext.log 里的中文也会乱码，容易被误判成界面乱码。

二、架构自适应统一包（不用再分辨 x64 / arm64）

新附件	内容	体积
Windows-universal-2.1.6.exe	一个 exe 内含 x64 与 arm64 两套运行时与两套 Skiko，启动时按 PROCESSOR_ARCHITECTURE / PROCESSOR_ARCHITEW6432 自动选择	约 175MB
Linux-universal-2.1.6.tar.gz	一个包里含两套运行时与两套 app 目录，bin/jmnext 按 uname -m 选择	约 159MB

原有的按架构包全部保留（体积更小，适合知道自己架构的用户），所以本版附件比 2.1.5 多两个。

没有改的地方（以及为什么）：

• APK 本来就是自适应的：aapt2 显示 native-code 已覆盖 arm64-v8a、armeabi-v7a、x86、x86_64 四个 ABI，
  dex 与架构无关 —— 同一个 APK 在 arm64 与 x86_64 上都能装能跑。full/lite 的差别是功能，不是架构；
• deb / rpm / AppImage 只能按架构：架构写在包元数据里（内含架构相关的 JRE，不能声明成 all），
  AppImage 的外层运行时本身就是架构相关的。

一处值得记的结构差异（做统一包时才暴露）

jpackage 生成的 app-image 里 lib/runtime 没有 bin/java —— 它靠自带的 ELF 启动器经 libjli 启动 JVM。
统一包改用 shell 启动器，所以 arm64 那一半必须换成带可执行文件的运行时，做法是用 jlink 按该运行时
自己的 lib/modules 生成（java.base / java.datatransfer / java.desktop / java.logging / java.prefs / java.xml / jdk.crypto.ec）。

未验证

• 汉字是否真的显示正常：必须由你在 Windows 上看。若仍是方框，说明你机器上缺少可用的中文字体，
  那就需要下一版打包一个字体（Noto Sans SC，约 5-10MB）。
• 两个统一包只做了结构验收（架构正确、文件齐全、启动脚本含架构判断）：能否真的启动需要你或群友实测。

2.1.5 — 修复 Windows 单体 exe（条件解压 / 工作目录 / 崩溃可诊断）

2.1.5 — Windows 单体 exe 修复

问题修复：单体 exe 启动失败/无反应。与可用的 ZIP 逐字对比后找到三处差异并全部修好：条件解压（不再每次重解 150MB）、切换工作目录对齐 ZIP、放入 run.bat 让崩溃可诊断。打包者注：修复后的 exe 已由用户实测确认可以启动。附件矩阵与前几版相同。

问题修复：Windows 单体 exe 启动失败/无反应（用户报告 jar 版与 ZIP 版正常，单体 exe 炸了）。

与可用的 ZIP 版逐字对比后，单体 exe 少做了三件事，任一件都足以造成"点了没反应"的表象：

1. 每次启动都重新解压约 150MB（File /r 无条件执行）—— 静默 + 无窗口，用户看到的就是"点了没反应"。
   现改为按版本标记条件解压（.installed-<版本> 存在则跳过）。
2. 没有切换工作目录到应用目录 —— ZIP 的 jmnext.bat 一直有 cd /d "%~dp0"，单体 exe 漏了这一步。
   现在用 SetCurrentDirectory 对齐。
3. 崩了没有任何输出 —— javaw 不弹控制台，SilentInstall silent 连错误框都没有，等于没有线索。
   现在应用目录里放一个 run.bat（java.exe + 完整 classpath + pause），双击即可看到报错；
   另外应用本身已把 stdout/stderr 写进 %USERPROFILE%\jmnext.log，可直接取用。

未验证（重要）

我无法在 Windows 上运行，所以"是否真的能启动了"必须由你确认。如果 2.1.5 的单体 exe 仍然打不开，请把下面任一信息发我，
我就能定位到确切原因（此前是没有线索才只能推断）：

• 双击应用目录里的 run.bat，把窗口里的内容发我；
• 或把 %USERPROFILE%\jmnext.log 发我（应用自己写的日志，第一行就是版本与构建时间）。

两处都为空则说明 JVM 根本没起来（多半是杀软拦截或架构不匹配），那种情况请也告诉我，我换一种打包方式。

2.1.4 — 修复 issue #3（屏蔽不生效 / 随机推荐生效时机 / 搜索页筛选）

2.1.4 — issue #3 修复

问题修复：首页「最新上架」补齐标签屏蔽；随机推荐改为整批读标签（可见的排队首），不再自己翻过去一遍才生效；搜索页排序/检索筛选改为随内容滚动。附件矩阵与前几版相同。

问题修复（issue #3）：部分场景屏蔽不生效、随机推荐要"翻过去一遍"才生效、搜索页筛选常驻。

A. 首页「最新上架」不屏蔽

分区（推荐位）那套"过滤 + 逐条请求标签"本来就有，但**「最新上架」这条列表既不过滤也不请求标签**，所以命中屏蔽规则的作品照样出现。已补齐。

B. 随机推荐要自己翻过去一遍才屏蔽/排序

原因是 1.6.0 的一次优化：逐条读标签从"整批"改成只读屏幕上可见的（本意是避免用户只看前三行却发二十几个详情请求）。
副作用是屏蔽与排序都依赖标签，没滚到的条目永远没有标签 —— 于是必须自己翻过去一遍才看到生效。

现在的取舍：整批读当前一批（通常二十几条），但把可见的排在最前，所以屏幕上看得见的先出结果、其余陆续补上；
共享缓存与并发上限 3 保持不变，不会重复请求、也不会突发压住服务端。

C. 搜索页的排序/检索筛选常驻

两行筛选原本在滚动容器之外、永远固定在搜索栏下面（issue 说"优先级过高"）。现在作为结果的首个列表项随内容滚动；
并抽成 SearchFilterRows 在"有结果"与"空结果"两支各用一次。空结果那一支也显示筛选 ——
提示语写着"换个关键词，或调整检索字段与年份"，此时把筛选藏起来会自相矛盾。

未验证

• 用真实账号与真实屏蔽规则验证"首页最新上架立即过滤"的观感；
• 整批读标签后，进入随机推荐页的首批请求量是否可接受（并发仍是 3，只是不再按可见性分期）；
• 桌面端：对应的屏蔽路径已按代码核对本就在应用（桌面首页布局与 Android 不同，没有同名分区），
  但我没有在真桌面上逐屏确认过 —— 这一条只有代码层证据。

（此前的 2.1.3 已完成交互专项的加载态补齐；本版是 issue #3 的修复。）

2.1.3 — 加载态补齐（转圈与错误分开）

2.1.3 — 加载态补齐（交互专项第五项）

小功能（+001）：桌面端各页面此前只有一行不动的文字状态，慢网络下像卡住。本版抽出 LoadingHint 与 StatusLine，接入 14 处；详情页与阅读页各自把 pending 与 error 拆开（此前同一 status 兼表两者，直接加转圈会出错时一直转）。附件矩阵与前几版相同。

小功能（+001）：加载态补齐（交互专项第五项）。 审计发现桌面端 17 个文件只有文字状态、仅 1 个文件有进度指示 ——
慢网络下用户看到的是一行不动的字，像卡住。

做法：先拆语义，再补视觉

详情页与阅读页此前用同一个 status 同时承载"正在加载…"与"加载失败：…"。若直接加转圈，出错时也会一直转，
所以先加 loading 布尔（成功与失败都置假），再让它决定画什么：

• LoadingHint：细转圈（16dp、2dp 线宽，尺寸取小不抢内容位置）+ 文案；
• StatusLine(status, busy)：进行中画转圈，否则画普通文案。样式与颜色做成参数，默认值和各页原来完全一致，
  没有显式颜色的页面显式传 Color.Unspecified 以保持跟随 LocalContentColor。

共接入 14 处；Android 端审计显示加载态覆盖已较好，未动。

明确不改的地方（有意为之）

• 追更页：它父组件的 status 是操作结果（"已取消追更 n 部"），不是加载中；加转圈会让"已完成"看起来一直在进行；
• 顶栏标题不做文本可选（紧邻返回键，选字与点击冲突）；
• 删除屏蔽规则不加确认（可逆，过度确认是反模式）；
• 按钮文案、标签、列表标题不做可选（会与点击、拖拽冲突）。

未验证

• 加载态的真实观感：转圈大小与位置是否合适、快速返回时会不会"闪一下"（本地回环很快，只有真网络才有意义）；
• 瞬时反馈的停留时长（普通 2.4 秒 / 失败 4.8 秒）、焦点环粗细与颜色、确认对话框文案是否说清后果。

若确认会闪，下一版可加"延迟 150ms 才显示"或"最短显示时长"来消除 —— 这属于新行为，本版未做。

关于 2.1.2 的一处更正

2.1.2 首次发布时误发了两个装不上的 Android 包（只有 classes.dex、缺 manifest 与资源，
aapt2 报 could not identify format），发现后已撤下并补上验证过的包。根因是更早一次编辑误删了
android.enableResourceOptimizations=false。此后发布流程新增断言式验收（verify-apk.sh：
aapt2 必须输出 package: 行、包内必须含 AndroidManifest.xml 与 resources.arsc、包名与版本必须匹配）。

2.1.2 — 交互逻辑专项（瞬时反馈 / 焦点 / 确认 / 可复制）

2.1.2 — 交互逻辑专项（前四项）

小功能（+001）：两端加入瞬时反馈（此前操作做完毫无反馈）、桌面端焦点可见与搜索 Esc、退出登录先确认、详情信息与错误文案可选。附件矩阵与前几版相同：Windows ZIP 与单体 exe 各两个架构、Linux tar.gz/deb/rpm/AppImage 各两个架构、Android full/lite。

小功能（+001）：交互逻辑专项（前四项）。 起因是一次交互审计，发现两端最大的缺口不是动画，而是
"操作做完没有任何反馈" 与 桌面端只能鼠标操作。

一、瞬时反馈（两端都有了一条提示通道）

审计时两端 Snackbar/Toast 计数都是 0：桌面端的收藏、追更、点赞只写日志，用户看不见结果。
本版加了统一的瞬时反馈：

• 机制两端同实现，交互细节有意设计：同一条消息重复触发按序号重新计时（连点两次不会提前消失）、
  失败停留时间是普通提示的两倍（要看清原因）、提示层不挡操作、进出场走本平台动效 token；
• 已接线：桌面端点赞、追更、屏蔽标签、标星成功/失败；Android 签到（三个结果分支）；
• Android 详情页刻意不加：它本来就有内联提示条（actionNotice），再加一层是冗余。

二、桌面端键盘与焦点

• 焦点可见：此前 jmClickable 为了去掉涟漪传了 indication = null，把默认焦点指示也一并去掉了，
  于是 Tab 走到封面或按钮上看不出在哪。现在被聚焦的元素会描一圈主色边框（只改颜色不改尺寸，不引起布局跳动）；
• 搜索框：Enter 搜索，Esc 清空并收起结果；
• Esc 关闭弹层本来就支持（唯一的 Compose 弹层用 AlertDialog(onDismissRequest = …)，框架会映射 Esc）。

三、破坏性操作确认

桌面端退出登录改为先确认再执行（此前点一下就退出）。Android 侧原本已有收藏夹删除等确认对话框。
有意不加的：删除屏蔽规则 —— 它可逆（再点一次即加回），过度确认会让每次清理都多一步。

四、文本可选

桌面端详情页的信息值（标题、作者、作品 id）与状态/错误文案改为可选：前者常要复制去搜索，
后者常要贴给别人看。有意不铺开：按钮文案、标签、列表标题若也可选，会与点击、拖拽冲突。

未验证

与前几版一致：只有编译与打包验收证据。本版尤其需要你的眼睛 ——
提示停留时长是否舒服、焦点环粗细与颜色是否够醒目、确认文案是否说清后果、可选文本范围是否合适，
这些我在这里都看不到，只能由你在真机/真桌面判定。

未做

加载态补齐（桌面端 17 个文件只有文字状态、仅 1 个文件有进度指示）。这项需要区分 pending 与 error
两种语义（现在详情页用同一个 status 承载两者），改的是各页的加载状态机，留待下一版。

2.1.1 — 桌面端真正的共享元素

2.1.1 — 桌面端真正的共享元素

小功能（+001）：桌面端接入真正的共享元素（封面从列表位置连续过渡到详情位置），取代 2.1.0 的近似效果。桌面端与 Android 同一提交、同一矩阵：Windows ZIP 与单体 exe 各两个架构、Linux tar.gz/deb/rpm/AppImage 各两个架构、Android full/lite。

小功能（+001）：桌面端补上真正的共享元素，取代 2.1.0 里的近似效果。

改了什么

2.1.0 的桌面端只有"详情页封面自身放大淡入"的近似；本版接入真正的共享元素：
打开详情时，封面会从列表里的位置连续过渡到详情页里的位置，而不是各自淡入。

实现与 Android 侧同结构：根部 SharedPageHost 建一层 SharedTransitionLayout 并通过
CompositionLocal 提供两个作用域（共享作用域 + 页面动画作用域），列表封面与详情封面各用
同一个 jmCoverKey(漫画 id) 登记。拿不到作用域时会退化为"什么都不做"而不是崩掉。

为什么值得单独一版

这是本轮动效改造里唯一"跨层"的改动（要同时动路由层与两个页面），因此单独提交、单独验证，
一旦手感不对可以整版回退，不影响 2.1.0 里其它动效。

未验证

与 2.1.0 同样的边界：只有编译、单测与打包验收证据。共享元素的实际观感
（封面是否真的"飞"过去、位置与缩放是否自然）没有任何真机/真桌面观察记录，需要使用者确认。
若观感不对，回退本版即可回到 2.1.0 的近似效果。

2.1.0 — 动效改造（桌面端从零补齐）

2.1.0 — 动效改造

大功能（+010）：桌面端动效从零补齐（图片淡入、列表项动效、交互反馈、路由转场、动效 token），Android 增加全局图片淡入。桌面端与 Android 同一提交、同一次构建，两个架构（x64 与 aarch64）同步更新。

大功能（+010）：动效改造。 起因是长期反馈"动画太僵"。诊断后发现主因不是缺特效，而是
桌面端几乎没有动效、且两端都没有统一的动效约定：桌面端 19 个懒列表、11 条路由、所有点击反馈
此前都是瞬变；Android 侧已有主题化的动效参数（ui/theme/ThemeStyle.kt 的 MotionSpec
按视觉风格各带一套）与真正的共享元素，桌面端则从零开始。

桌面端（本轮主体）

改动	效果
封面图片淡入	从空/占位到实图不再是瞬变
9 处懒列表 Modifier.animateItem()	列表增删与重排是位移过渡
新增 Modifier.jmClickable()	悬停轻微放大 + 底色、按下回缩（此前桌面端几乎没有交互反馈）
路由转场 AnimatedContent	页面切换是淡入 + 横向轻移，不再硬切
详情页封面进入	轻微放大 + 淡入（近似共享元素，见下）
新增 Motion.kt	时长与缓动集中一处，改手感只改这里

Android

• 全局图片淡入：ImageLoader.crossfade(true)，一处生效覆盖全应用；
• 其余动效（转场、列表项、共享元素、主题化动效参数）本已存在，本轮未改 —— 避免在没有真机对比的情况下
  改动已知可用的手感。

明确未做的部分

桌面端真正的共享元素（SharedTransitionLayout + sharedElement，让封面从列表位置连续放大到详情位置）
未实现：它需要把 SharedTransitionScope 从根部一路传到列表与详情两处，改动面比本轮其它改动加起来都大。
本版桌面端只有近似效果（详情页封面自身放大淡入，不是跨页面连续过渡）。Android 侧是真实现。
若近似效果够用，就不必付那份复杂度；不够用再单独做一版。

未验证

与前几版一致：本版只有编译、单测与打包验收证据。动效的手感（快慢、幅度、是否跟手）没有任何
真机/真桌面观察证据，需要使用者确认。另外提醒一处只有肉眼能发现的坑：AnimatedContent 块内若误用
外层状态而非动画提供的 target，动画会"空转"（新旧两帧渲染同一页面），编译不会报错 —— 本轮已踩到并修正。

2.0.2 — 标签屏蔽覆盖全部列表页

2.0.2

代码更新（小功能 +001）：桌面端标签级屏蔽补齐到全部列表页（首页/分类/随机/作者/更多）；Daily 纯逻辑移进 shared。附件矩阵与 2.0.1 相同：Windows 免装 JRE 的 ZIP 与单体 exe 各两个架构、Linux tar.gz/deb/rpm/AppImage 各两个架构、Android full/lite。

本版是代码更新（小功能 +001）：桌面端的标签级屏蔽补齐到全部列表页。

标签级屏蔽覆盖全部列表页

此前只有搜索页接了标签级屏蔽；本版把它接到首页、分类、随机、作者、更多五处，语义与搜索页一致：
被挡的条数会明示（并列出命中的标签），并提供「允许一次」，不做静默丢弃。
实现上抽出共用三件套（命中集合、按 id 拆分、提示条），因此不同页面里元素类型不同
（ListItem、CreatorAuthor、CreatorWork）也能复用同一份逻辑。

内部整理

Daily（签到里的纯逻辑：已签天数、总数、「全部签完」「已经签过了」的判定）从 app 移到 shared。
它只依赖 shared 的 DTO，包名保持 com.jmnext.data，因此 app 侧 import 一行未改；移动后两端共用同一份，
避免两端各写一遍这类最容易写反的判定。

与 2.0.1 的关系

2.0.1 只改交付与命名（产物命名统一、Windows 单体 exe、Android 首页标题），本版才带代码改动。
两个版本的产物命名规则相同（平台-架构-版本），附件矩阵一致：Windows 免装 JRE 的 ZIP 与单体 exe 各两个架构、
Linux tar.gz/deb/rpm/AppImage 各两个架构、Android full 与 lite。

未验证

与其他版本一致：本版只有编译、单测与打包验收证据，没有真机运行时验证。
标签屏蔽的真实过滤效果、以及两个 exe 在 Windows 上的实际运行，都需要真机反馈。