100 Commits
Author SHA1 Message Date
mole404 f99c392061 chore(release): 3.5.2 2026-10-04 14:39:00 +08:00
mole404 e5e925c579 fix(delete): 删完把卡片从 DragSelect 的两个集合里摘掉
症状(老师报的):选中图片删除后顶部选中状态不重置 —— 操作栏不收回,
之后任何一次重画又会显示「已选择 N 张图片」,再选一张时计数虚高(实测 1 张显示成 2 张)。

根因:删除成功那支只做 $(item).remove(),没把卡片从 DragSelect 的 SelectedSet /
SelectableSet 里摘掉。DS 的 getSelection() 就是 `return SelectedSet.elements`,
全库没有一处 isConnected 判断 → 已删卡片成为「幽灵选中项」;而顶部标题与操作栏
完全由 bindOperates() 按 getSelection() 渲染(挂在 elementselect/elementunselect 上),
所以之后任何一次重画都会带着幽灵重画。

修法(实测两个候选,取更干净的 A):
  ds.removeSelectables(selected);   // 从可选集合摘掉
  ds.removeSelection(selected);     // 从选中集合摘掉(发 Selected:removed → 自动重画)
  bindOperates();                   // 兜底,顶部统一回「未选中」

验收(真 jQuery + 真 ds.min.js + 逐字抽出的本文件代码,jsdom):
  删完 → 标题「我的图片」、可见操作项只剩 [refresh]、getSelection()=0、getSelectables()=2;
  重画后仍正确;再选一张显示「已选择 1 张图片」。

同步:Dockerfile 两处 blade md5(自证段 + .code-revision 生成段)重钉为
d9ffacb2bbd8905703c279965a07ddbf;patches/ios-longpress.patch 重生成(并把此前记错的
「上游原文件 md5」更正为 22c896eb7322ec2ff37d5eddd7ca0dec)。
2026-10-04 14:39:00 +08:00
mole404 1280cafe90 Update README.md 2026-10-04 14:37:19 +08:00
mole404 d2291991c1 Update README.md 2026-10-04 03:48:06 +08:00
mole404 f4c799477a chore(release): 版本号一律不带 v —— app 显示与镜像 tag 统一为 X.Y.Z
老师 2026-10-03 定:所有版本号逻辑去掉 v 前缀。
  · src/config/app.php: 'v3.5.1' → '3.5.1'
  · build-image.yaml / backfill-version-tag.yaml 的格式守卫:^v[0-9]+… → ^[0-9]+\.[0-9]+\.[0-9]+$
  · 新增 delete-image-tag.yaml:手动删 tag 入口(本机 token 无 packages 权限,只能走 CI)

镜像 tag 由 app.php 的 version 单一事实来源自动跟随 ⇒ 一处改、两处生效。
GHCR 上旧的 v3.5.0 / v3.5.1 用该入口删除,此后版本号只保留 X.Y.Z 形式。
2026-10-04 03:26:45 +08:00
mole404 f82f4b0942 Fix formatting of latest version in README 2026-10-04 03:14:16 +08:00
mole404 fd8217afbf Update README.md 2026-10-04 03:13:57 +08:00
mole404 79f9f2ed30 fix(ci): 补打工作流避开 pipefail 假红(inspect | head → 先落文件)
上一版补打**其实成功了**:GHCR 上 v3.5.0 的 digest 与 sha-0caef9ca 完全一致。
但运行显示红色 —— 脚本开了 set -o pipefail,而
  docker buildx imagetools inspect ... | head -8
里 head 提前退出,docker CLI 吃到 SIGPIPE 后以非 0 退出(本次实测 exit 255)→
整条管道非 0 → 假红。build-image.yaml 里早就踩过同一个坑并写明「不在管道里接 head/grep」,
这里遗漏了。两处都改成「先落文件、再读文件」。

教训(这是今晚同类问题的第 N 次):修复脚本本身必须 set -euo pipefail,且断言要窄 ——
上一稿的修复脚本只写了 set -u,断言又过宽(命中注释里的 | head -1)当场失败后**继续往下跑**,
于是「以为改了、其实没改」,重跑的还是旧版本。
2026-10-04 03:13:28 +08:00
mole404 9037691995 ci: 加「手动补打版本号 tag」工作流(独立文件,不碰主发布流程)
用途:给**已发布过的历史镜像**补一个版本号 tag,日后能靠版本号拉回旧正式版。
本次要补的:现行正式版 0caef9ca… 补 v3.5.0。

为什么单独一个文件:
  · on: 里只有 workflow_dispatch ⇒ 推代码不会启动它,不影响正常发布;
  · 也不必改 build-image.yaml 里那段已被反复验证的 promote 逻辑,改动风险为 0。

为什么它不会变成「用版本号拉到 test 镜像」的后门 —— 四道守卫:
  ① 格式必须 vX.Y.Z;
  ② Compare API 强制要求目标 commit 在 master 上(test 的 commit 直接拒绝);
  ③ 目标镜像 sha-<commit> 必须真的存在(不能凭空造 tag);
  ④ 版本号 tag 已存在则保留原样、绝不覆盖。
(本地补打之所以失败是 401 —— 本地 token 缺 packages:write;CI 里 GITHUB_TOKEN 有。)
2026-10-04 03:10:32 +08:00
mole404 cdd4eb7d2e chore(release): 版本号改 v3.5.1 + promote 时同步打版本号 tag
版本号机制(老师 2026-10-03 定):
  · latest 永远 = master 最新正式版(原有行为不变);
  · 每个正式版额外留一个**不可变**的版本号 tag(vX.Y.Z),日后可靠它拉回旧正式版;
  · **无论如何都不能靠版本号拉到 test 分支的镜像** —— 结构性保证:promote 步骤的 if 写死
    github.ref == 'refs/heads/master',分支构建根本执行不到打 tag 那几行。

版本号来源 = src/config/app.php 的 version(单一事实来源,与 PIN 从 Dockerfile 解析同一原则),
本次 v3.5 → v3.5.1。

三道守卫:
  ① 格式必须 vX.Y.Z;
  ② 用 Compare API 确认本 commit 确实在 master 上(挡住 workflow_dispatch 在别的 ref 上手动跑);
  ③ 版本号 tag 已存在则保留原样、绝不覆盖(这正是「靠版本号拉旧版」能成立的前提)。
2026-10-04 02:59:46 +08:00
mole404 0c24398130 fix(viewer): 桌面端看图器开关不再横向重排 —— html{scrollbar-gutter:stable}
症状(仅桌面端):图库里有滚动条;点开图片后滚动条消失,页面重新排版(内容右移约 8~9px);
关闭看图器滚动条回来,又跳一次。

真机实测的依据(老师给的 console 数字):
  · 图库时滚动条宽 = 9px(Win11 细滚动条)
  · 打开看图器后 body 补的 paddingRight = 0px   ← 库完全没补上
根因:viewerjs 的 scrollbarWidth 只在 new Viewer() 那一刻量一次(render.js initBody),
那时文档还没溢出、压根没有滚动条,于是量到 0 —— 之后 paddingRight 恒为 0,永不更新。
截图像素级取样也印证:内容右边界从 ~1262 移到 ~1270,与 9px 滚动条吻合。

修法(老师选定的方案①,只动一行 CSS):给 html 预留滚动条位置
  html { scrollbar-gutter: stable; }
滚动条即使因 .viewer-open{overflow:hidden} 消失,那 9px 也仍被预留 ⇒ 布局宽度不变
⇒ 无从重排。此法与「库量到多少」无关,不依赖那个恒为 0 的值。

回归:9 套守卫测试全绿。
2026-10-04 02:45:59 +08:00
mole404 0b4df0faa0 fix(scroll): 修正上一稿的半拉子——app.js 里那两道旧闸门这次真的撤掉了
上一稿的替换脚本在改 app.js 时断言失败,但脚本没有停止,用旧的 app.js 继续构建、测试
并上线了(守卫测试全绿,因为旧版本本来就能过)—— 结果是 blade 已只留「重置窗口」,
app.js 里却仍然挂着「认手指」的第二道闸与滚动停止复查。

本版:app.js 干净回到 0caef9ca 的 onScroll,只插入「重置窗口」这一道闸,确认无
recheckTimer / __lskyScrollGate 残留;构建前过语法自检;脚本改为 set -eu —— 任何一步
失败立刻停,不再带伤上线。
2026-10-04 02:25:24 +08:00
mole404 ac428c2e6b fix(scroll): 闸门只留「重置窗口」——撤掉会把真实滑到底一起堵死的手指闸门
上一版加了两道闸:「最近 700ms 内有 touchmove/wheel 才算用户驱动」+「滚动停止后复查」。
守卫测试立刻拦下(infinite-scroll-bottom-mobile / click-delegate / destroy 三套全红,失败项
正是「到底了但不触发加载」),与老师真机上报的「滑到底不自动加载」完全一致 —— 说明方向错
了,不是参数没调好。

结论:A 方案(关滚动锚定 + 关刷新位置恢复 + 重置前先回顶部)已经把「无脑滚到底」治住,
额外的「谁在驱动滚动」闸门是多余复杂度,且会误杀真实滚动(滑到底那一刻可能刚处在窗口边缘,
当场被拦后又不再有 scroll 事件 ⇒ 永远不加载)。

本版:只保留 resetImages 开的 800ms「重置窗口」这一道闸,其余一律放行。
(另:上一稿用字符串切片改坏过 blade 的 script 块,被语法自检当场拦下、未推 —— 已改为
精确整段替换,并把「改完先跑 script 块语法自检」固定进流程。)
2026-10-04 02:18:33 +08:00
mole404 e63b5ddb53 fix(scroll): 治「换排序/刷新后无脑滚到底」(安卓 Edge)
页面侧(images.blade.php):
  · 关掉浏览器滚动锚定:html, body, #images-scroll, 哨兵 { overflow-anchor: none }
  · history.scrollRestoration = 'manual',刷新不再被拽回原位置
  · resetImages 里「先 window.scrollTo(0,0) 再清空」——清空后高度塌缩会把滚动位置夹到浅处,
    再叠加重排补滚就是连锁的起点
  · resetImages 开一个 800ms 重置窗口,这期间忽略滚动触发的加载

无限加载侧(app.js onScroll):
  · 闸门 1:距上次「用户真实向下滚动」(scrollY 增加 >4px)不足 150ms 不放行 ——
    浏览器为维持滚动位置自动补的那一滚不更新时间戳,所以补滚最多带出已有那一页,不连锁
  · 闸门 2:重置窗口内不放行

注:Claude 的分析里漏了 refresh(params) → load(params, true) 这条 —— force 会无视
「正在加载/已到底」直接发请求,是连锁能成立的另一半。本次两道闸门把它一并管住。
回归:9 套测试全绿(infinite-scroll-bottom-mobile / click-delegate / destroy 等)。
2026-10-04 02:02:00 +08:00
mole404 0caef9cac0 fix(viewer): 用 CSS 把切图过渡的起点钉在屏幕中心(保留动画,去掉造成忽有忽无的关过渡补丁)
老师反馈两点:① 反向切换(图都已加载完)时仍有时带过渡、有时不带;② 想要保留过渡
动画,"直接闪出来"效果差。复核后定位到两条:
  · 上一版的 1 秒兜底定时器:慢图(>1s 才加载完)会在库读 options.transition 之前先被
    恢复,于是过渡又生效 —— 这是"有时有动画"的来源之一。
  · 上一版还有一把锁:只有上一次已恢复(saved === null)时才去关过渡。若 1 秒内连续切
    (或 viewed 未到),这一次就不关 ⇒ 又带过渡。两条叠加就表现为"忽有忽无"。
既然老师要动画,方向改为"保留库自带的过渡,把起点钉死":

  库每切一张新建 <img>,刚插入时用默认 CSS(满宽、贴顶);加载完成后才写内联样式:先写成
  "屏幕中心的一个点",再写最终尺寸,靠 CSS 过渡补间。过渡起点 = 浏览器上一次渲染过的样式,
  哪一帧被渲染由缓存/网速/主线程决定 —— 渲染到"满宽贴顶"那帧就会从上方飞入。

  对策(不动库任何逻辑):用 :not([style]) 只命中"还没有内联样式"的那一瞬,把这一瞬做成
  屏幕中心的小点。库一写内联样式该规则立即失效,因此绝不影响最终显示,也不会与库打架;
  过渡仍是库自带的,所以动画完整保留。

本次移除上一版"临时关 options.transition"的整段补丁。
本机验收:9 套 jsdom 守卫测试全绿;浏览器六项全过(拖动跟手+回弹、横划 120px 切、
竖划不切、中途不翻页、捏合 351→1615、双击 1615→2751、切图后不误关);
飞入专项按 Claude 的延迟加载法执行;最终显示核对(宽度非 1px、opacity=1、已写内联样式)。
注:本机模拟环境复现不出真机那个飞入,最终以真机为准。
过程记录:本轮先被守卫拦下一次(把 CSS 误放进 <script> 块,测试会把 script 内容当 JS 跑),
已挪到 <style> 块并重跑,未影响线上。
2026-10-03 15:28:51 +08:00
mole404 5067ed817b fix(viewer): 切图取消过渡动画(Claude 方案 B),去掉真机上无效的强制回流方案
老师真机反馈:方案 A(强制回流固定动画起点)仍会从屏幕上方飞入。
  说明"提交中心点那一帧"在真机上依然不可靠(哪一帧被渲染由缓存/网速/主线程决定)。
  既然起点问题只在"有过渡"时才存在,索性取消这一下的动画。

做法:包一层 viewer.view,当目标 index 与当前不同且查看器已打开时,把
options.transition 临时置 false(load() 读到 false 就不加过渡类、回调照常执行),
在 viewed 事件里恢复,并加 1 秒兜底定时器防 viewed 未到而卡住。
必须走 options.transition 开关,不能用 CSS transition:none 去压 —— 否则 renderImage
永远等不到 transitionend、viewed 不触发、手势会被卡死。
路径覆盖:next()/prev() 内部调的都是 this.view,所以手指滑动、缩略图条、键盘、底部按钮
都会经过这里。
防御:测试环境里的 Viewer 是替身(没有 view/element),此时整体跳过。

本机验收(注入真实版本后):9 套 jsdom 守卫测试全绿;浏览器六项全过
(拖动跟手+回弹、横划 120px 切、竖划不切、中途不翻页、双指捏合 351→1615、
双击放大 1615→2751、切图后不误关);飞入专项 2/2 差值 0px。
注:本机"延迟加载"复现法测不出真机那个飞入(方案 A 在本机也是 0px),故真机为准。

过程记录:本轮先被仓库守卫拦下两次(脚本写歪留下孤立大括号;误把 context-js 的 md5
当成 blade 的),均已修正后重跑,未影响线上。
2026-10-03 15:08:36 +08:00
mole404 4085642695 fix(viewer): 切图动画起点固定为屏幕中心(强制回流),并删掉上一版无效的摘类补丁
老师反馈上一版没修好(附真机截图)。按 Claude 的静态分析复核后确认,根因是 view() 的时序竞态:
  · view() 每次都新建一个 <img>:先写成"屏幕中心的点"(宽高 0 + margin 居中),读自然尺寸后
    再加 viewer-transition 写最终尺寸,靠 CSS 过渡补间。
  · CSS 过渡的起点 = 浏览器"上一次真正渲染过的样式"。第 1 步默认样式是"满宽贴顶",第 2 步是
    "中心点",第 3 步是最终值。哪一帧被渲染过决定动画从哪开始:第 2、3 步之间有帧 ⇒ 从中心
    长出来;只渲染到第 1 步 ⇒ 从屏幕上方飞入;一帧都没渲染 ⇒ 无动画直接出现。取决于图片是否
    缓存、网络快慢、主线程是否空闲 —— 这就是"没规律"的来源。
  · 上一版在 pointerup 里 viewer.image.classList.remove('viewer-transition') 无效:view() 新建
    的是另一个 <img>,且 load() 会按 options.transition 给新图重新加类。已删除该段及错误注释
    (原注释"从上一张图 margin 滑过来"也不成立)。

修法(Claude 方案 A):包一层 viewer.initImage,在它读自然尺寸之前强制回流一次
(void viewer.image.offsetWidth),把"中心点"提交为已渲染样式 ⇒ 起点恒为屏幕中心。
覆盖手指滑动、缩略图条、键盘、底部按钮等所有切图路径(都在 view() 内)。

本机实测(延迟图片响应 + 限速,模拟"未缓存的大图",即 Claude 给的复现法):
  切换瞬间 top 与稳定后 top 的差值:A 组 0px / 0px,C 组重跑 0px / 0px ✓
  对照组(剥掉补丁)未取得有效数据(生成对照版本时脚本把页面切坏),"无补丁会飞"留待真机确认。
本机 9 套 jsdom 测试全绿。
2026-10-03 14:49:22 +08:00
mole404 bcbdbd765c chore(version): 后台「关于」版本号 v3.2 → v3.5
先确认过风险:entrypoint.sh 的 auto_migrate() 不读这个版本号,它直接比对
「镜像里的迁移文件」与「数据库 migrations 记账表」(SQLite 走只读探测,
读不到记账表就整体跳过)。所以改这个值纯粹影响显示,不会触发迁移。

与上一轮署名改动(已单独发布)合计后,后台「关于」显示为:
    v3.5
    By Mole404 & DeepSeek & Claude

本机 9 套 jsdom 测试全绿。
2026-10-03 14:25:05 +08:00
mole404 82fa68256a chore(about): 后台「关于」署名改为 By Mole404 & DeepSeek & Claude
- config/app.php 的 'author':mole404 → Mole404 & DeepSeek & Claude
- admin/setting/index.blade.php:模板里的 "by" 改为 "By"(前缀写在模板里,
  值里就不再重复写 By),最终显示为一行:
      By Mole404 & DeepSeek & Claude

版本号本次不动(老师要求分两次构建:本轮只改署名)。
本机 9 套 jsdom 测试全绿。
2026-10-03 14:18:49 +08:00
mole404 1e5bac3c17 fix(viewer): 切图不再从偏移位置"飞入"(切的那一瞬摘掉过渡类)
老师反馈上一版的 viewer.reset() 没治到根(附了瞬间截图)。读源码确认:
  · reset() = this.imageData = initialImageData; renderImage() —— 它自己也是带动画的,
    所以"先 reset 再切"只是把过渡的起点从"被平移的偏移量"换成"复位中间态",照样滑。
  · 库的过渡本质是"从上一张图的 marginTop/marginLeft 滑到新图的 margin"(renderImage 直接
    写 width/height/margin,靠 CSS transition 补间)。两张图高度不同(横图↔竖图)时,
    新图就会从偏上/偏下的位置滑进来 —— 这就是"有时正常、有时从上面飞"的根因,与拖动无关。

修法:切图这一瞬先摘掉过渡类 viewer-transition,再 next()/prev() ⇒ 新图直接出现在它该在
的位置(观感即"从中间出来")。该过渡类是库自己在管理的(action 为 move/zoom 时它自己也会
摘掉),不属于那个碰不得的 action 状态机;renderImage 同一帧会按 options.transition 恢复它,
因此捏合/双击/平移不受影响。
同时去掉上一版那个无效的 viewer.reset()(它反而制造了另一个中间态)。

本机实测(390x844 + CDP 真触摸):
  【回归④切图不飞入】切换瞬间 top=-1582 → 稳定后 top=-1582,差 0px ✓
  ③ 切图后不退出查看 ✓   ① 捏合 351→1615 ✓   ② 双击 1615→2751 ✓
  拖动跟手/回弹 ✓   横划 20px·竖划 80px 不切 ✓   横划 120px 切 ✓   中途不翻页 ✓

本机 9 套 jsdom 测试全绿。
2026-10-03 14:13:07 +08:00
mole404 24afc03480 Update README.md 2026-10-03 14:03:18 +08:00
mole404 1564547216 fix(viewer): 切图前复位平移(不再从偏上位置飞入);切图后不再误关查看器
老师真机反馈两条,均已定位并修复:

① 切图时有时从靠上的位置"飞"出来。
   原因:库用 marginTop/marginLeft 定位,拖动时图片已被平移过,松手直接切图 ⇒ 新图从
   被平移的偏移量开始做 transition(手指带纵向位移时最明显)。修法:切图前先 viewer.reset()
   把平移复位,再从居中开始过渡。

② 手指在图片外空白处结束并抬起时,"切图成功"与"退出查看"同时发生。
   原因:抬手后浏览器补一发 click 落在背景上,库据此关闭查看器。修法:只吞掉紧跟切图之后
   400ms 内、且落点不在图片上的那发背景 click —— 正常"点背景关闭"不受影响。
   (历史上曾用 900ms 一刀切地吞 click,副作用是滑动后真双击失效,已废弃;本版条件精确得多。)

本机实测(390x844 手机模拟 + CDP 真触摸),六项全绿:
  未放大可拖动 left 20→-20→回弹 20 ✓   横划 20px/竖划 80px 不切 ✓   横划 120px 切 ✓
  中途不翻页 ✓   双指捏合 351→1615 ✓   双击放大 1615→2751 ✓
  【回归③】从图片内拖到图片外空白处抬起 ⇒ 查看器仍在 ✓(修复前会被关掉)

注:回归③的探针最初写错(用 offsetParent 判断可见性,固定定位元素恒为 null ⇒ 假阴性),
已改为 display/visibility。

本机 9 套 jsdom 测试全绿。
2026-10-03 14:01:56 +08:00
mole404 608a306a71 Update README.md 2026-10-03 14:00:18 +08:00
mole404 e7f9a80382 Update README.md 2026-10-03 13:58:17 +08:00
mole404 18514d9d2d Update README.md 2026-10-03 13:57:59 +08:00
mole404 b3698bd60f Update README.md 2026-10-03 13:57:09 +08:00
mole404 6f4f7ff219 Update README.md 2026-10-03 13:56:39 +08:00
mole404 97e5f2fbe1 Update README.md 2026-10-03 13:56:02 +08:00
mole404 a3f5c82287 feat(viewer): 关掉库自带触摸切图,改由松手判定 —— 未放大也能拖动、不再一碰就切
采用 Claude 提出的方案(第二步),替换此前所有"阈值接管"尝试。

为什么之前的尝试都不行:
  · 第 1 版在 pointerup 后 view() 弹回 —— 拖动中途库早已按 1px 判据翻页,事后补救无效。
  · 第 2 版从外面改写 viewer.action —— 库的捏合/双击/过渡全靠这个状态机,外部改写导
    致双指捏合失效、拖动带过渡延迟、切图错乱(老师真机实测四条全中)。
  · 第 3 版在 document 捕获阶段 stopPropagation 拦 pointermove —— 库用
    HAS_POINTER_EVENT ? 'pointermove' : 'touchmove' 选通道,真机可能走 touchmove,
    拦截整段失效;且监听器注册在库之后,同一节点同一阶段抢不到前面。真机实测无效。

本次做法(读源码 + 真机特征共同指向的最小改动):
  · new Viewer(...) 加 slideOnTouch: false —— 单指动作永远是 'move',库自带的平移就是
    跟手拖动;不再产生 'switch' 动作 ⇒ 1px 判据与 others.js 的 'switched' 闩锁都不存在。
  · 松手时自己判定:够远(> max(56px, 视口宽×0.18))或够快(> 0.5px/ms 且 > 30px),
    且横向占优(|dx| > |dy|*1.5)⇒ viewer.next(false)/prev(false);否则 viewer.reset()
    带动画回弹。放大态或第二指(捏合)出现时一律放权给库。
  · 全程不写库的内部状态,也不拦事件 ⇒ 不依赖 pointer/touch 通道,捏合/双击/过渡不受影响。

本机实测(390x844 手机模拟 + CDP 真触摸)全绿:
  【未放大可拖动】按下 left=20 → 中途 left=-20 → 松手回弹 left=20 ⇒ 跟手 ✓ 回弹 ✓
  横划 20px / 竖划 80px → 不切 ✓    横划 120px → 切 ✓    拖到 30px 中途 → 不翻页 ✓
  双指捏合 w 351→1615 ✓            双击放大 w 1615→2751 ✓
  注:放大态下本方案不接管切图(一律放权给库做平移),与上一版"放大后 120px 也切"不同。

本机 9 套 jsdom 测试全绿。
2026-10-03 13:28:21 +08:00
mole404 f535c8c6fb fix(viewer): 切图阈值改为"只拦事件、不碰库状态"(上一版改写 action 把捏合等全弄崩了)
上一版的做法是从外面改写 viewer.action。事后真机验证发现这是根本性错误:
库的捏合、双击、移动过渡全都依赖它自己的 action 状态机(handlers.js:367-375 在
pointerdown 一次性定值;指针移动时若 action 为 move 会摘掉过渡类 CLASS_TRANSITION)。
外部改写它 ⇒ ①双指捏合被覆盖失效 ②拖动带上 CSS 过渡延迟 ③切图行为一并错乱。
老师实测四条全中。本版彻底换方向,并已回退到 49ef183a 期间线上一律跑稳定版。

新做法(零改写):
  · 单指触摸、且位移尚未到阈值时,在捕获阶段 e.stopPropagation(),让库收不到这次
    移动 —— 它就不会切图。库的内部状态自始至终不碰。
  · 一旦划够阈值(未放大 60px、放大后 120px,且 |dx| > |dy|*1.2)立即放行,之后
    全部交给库原样处理(跟手切图本来就是它自带的行为)。
  · 多指(捏合)全程不干预:只要同时按下的手指数 > 1,本层立刻退出。
  · 非画布区域(缩略图条等)一律放行。

本机实测(390x844 手机模拟 + CDP 真触摸,含两项回归):
  捏合      w 351 → 1615 ✓         双击放大  w 1615 → 2751 ✓
  横划 20px / 竖划 80px → 不切 ✓    横划 120px → 切 ✓
  拖到 30px 中途 → 不提前翻页 ✓     库状态零改写(源码里仅存松闩那一处历史用法)✓
  「未放大也能拖动」本轮未做(风险最高,留第二轮):实测拖动时图片不动,属预期。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 13:04:42 +08:00
mole404 a1b5ff298d fix(viewer): 用"规范动作值"驱动切图/拖动,未放大也能拖动
上一版的两个问题一起修:

1) 切图失效(上一版把库的内部状态读回来又还回去)。库的 change() 一进 SWITCH 分支就把
   this.action 置成 'switched'(others.js:217,即"闩"),而这个值在外层 switch 里没有 case;
   把读到的值还回去,等于让库什么都不做 ⇒ 够格也不切图。实测确认:横划 120px 由"切了"
   变成"没切"。改为直接写两个确定的字面量(handlers.js:367-375 里库自己的取值就是
   'move' / 'switch'):
     未放大且划够 ⇒ 'switch'(库跟手切图)
     其余(未划够 / 已放大未够格)⇒ 'move'(库只平移)
   不再读取库的内部 action,避免再被闩住的值带偏。

2) 老师新需求:未放大时也要能拖动图片。未划够时给库 'move',于是 1:1 状态下拖动就是平移,
   而"稍动就切图"依然不会发生(划够 60px 且明显横向才变 'switch')。
   阈值维持老师定的:未放大 60px、放大后 120px,竖直方向一律不切。

验收脚本同时修了一处自身缺陷:原来按"面积最大的 img"取对象,图片被平移后会取错对象,
改为直接取 .viewer-canvas img。

本机实测(390x844 手机模拟 + CDP 真触摸)全绿:
  拖到 30px 中途 → 未翻页 ✓        松手后 → 未切 ✓
  横划 20px / 竖划 80px → 没切 ✓    横划 120px → 切了 ✓
  【未放大可拖动】按下 left=20 → 中途 left=-3 → 松手 left=-20 ⇒ 跟着手走 ✓,且未切图 ✓
  放大后两条:无头环境里"放大"这个动作仍没成功,两条实际跑在未放大状态,无有效数据;
  放大后的 120px 阈值待老师真机定手感。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 12:50:22 +08:00
mole404 71657705e3 fix(viewer): 切图阈值改为"过程中就不动作"(上一版只在松手后弹回,翻页那一下用户已看见)
老师反馈:上版"有变化但仍极度灵敏"。诊断:两个原因都占,主因是**库的判定在拖动过程中就已生效**——
上一版只在 pointerup 时判定够不够格、不够就 view() 弹回,但拖动中途库的 1px 阈值
(others.js change():absoluteOffsetX > 1)早就把图翻过去了,事后弹回补救不了观感。

本次改法:拖动过程中、尚未划够阈值时,直接把 viewer.action 设成 false ——
库的 pointermove 第一行就是 `if (!this.viewed || !action) return;`,于是它整段移动都不处理,
根本不会发生"先翻过去再弹回来"。一旦划够阈值,就把库自己算出的动作值(在第一次 move 时
记下的 savedAction)原样还回去,从那一刻开始跟手。
阈值也按老师要求钝化:未放大 40 → 60,放大后 80 → 120。
"弹回"保留为兜底(正常路径不会走到)。

本机实测(390x844 手机模拟 + CDP 真触摸),这次专门量"拖动中途":
  拖到 30px 中途   → 大图未变 ✓(上一版的破绽,本次治住)
  松手后           → 未切 ✓
  横划 20px / 竖划 80px → 没切 ✓(方向判据生效)
  横划 120px       → 切了 ✓
  放大后两条:无头环境里"放大"这个动作没成功(工具栏与滚轮都试过),两条实际跑在未放大状态,
  未取得有效数据 —— 放大后的 120px 阈值待老师真机定手感。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 12:43:01 +08:00
mole404 49ef183a8e feat(viewer): 手机端切图阈值接管(老师定的三条规则)—— 不再"稍动就切"
老师反馈:手机端切图手势过于灵敏(滑短短一下就切),想拖动基本都误触;而且"放大后能拖、
缩小后一拖就切图",阈值区间摸不透。

根源(源码核对):库把切图阈值硬编码成 1px(others.js 的 change():
absoluteOffsetX > 1 && > |offsetY|),而且"这一下是切图还是拖动"在 pointerdown 就按
"图片有没有超出屏幕"定死了 ⇒ 未放大时几乎必然判成切图、放大后又必然判成拖动 ——
规则本身不自洽,所以摸不透。

老师定的三条规则(实现如下,全部挂在外面,不改 viewer.min.js):
  · 未放大:横划跟手(库自带的行为保留),松手时 |dx| ≥ 40px 且 |dx| > |dy|*1.2 才切图,
    否则把已切过去的那张 view() 回来 —— 观感就是弹回原位;
  · 放大后:拖动看图照旧(库的 ACTION_MOVE),横划 ≥ 80px 才由本层补一次 view();
  · 竖直滑永远不切图(方向判据同时生效)。
判定用 pointer 事件(与库同一套),范围限定 .viewer-canvas 内,不碰缩略图条。

本机实测(390x844 手机模拟,CDP 真触摸):
  未放大 横划 20px  → 没切 ✓(期望不切)
  未放大 竖划 80px  → 没切 ✓(方向判据生效)
  未放大 横划 120px → 切了 ✓
  放大后 50px/140px 两条:无头环境里"放大"这个动作没成功(工具栏点击与滚轮都试过),
  所以那两条实际跑在未放大状态,未取得有效数据。放大后的 80px 阈值待老师真机确认手感。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 12:31:50 +08:00
mole404 58e24766fa fix(viewer): 关掉 focus(真因:view() 聚焦缩略图 li 把 overflow:hidden 的导航条滚走)+ 滚轮监听器改 passive
真因(Claude 定位 + 真 Chromium 对照验证,我核对源码确认):
  view() 摆放缩略图条之前会先对目标缩略图的 <li> 调 .focus()(源码 s.focus&&h.focus()),
  而 .viewer-navbar 虽然 overflow:hidden,仍是滚动容器 ⇒ 浏览器为了"让焦点可见"把导航条滚走
  (scrollLeft 推到最大);随后 renderList() 再叠一层 translateX ⇒ 位置被偏移两次,整条列表
  跑到屏幕外,只剩空黑底。
  表现:从靠前的图跳到很靠后的图(或关掉再打开靠后的图)后,缩略图条里靠后那批不显示、
  靠前的还在 —— 因为靠前那批本来就在初始可视区、不触发滚动。与"图是不是后加载的"无关,只与位置有关。
  真机对照:桌面跳到第 93 张 navScrollLeft 2439 / 可见缩略图 0 → 加 focus:false 后 0 / 43;
  手机 2573/0 → 0/15;关闭后重开第 100 张 2909/0 → 0/15。
  代价:关掉"打开后聚焦容器 + 焦点陷阱",对鼠标/触屏无影响,仅纯键盘 Tab 导航有差别
  (键盘切图与 Esc 关闭实测不受影响)。
  保留上一版的 update() 包装 —— Claude 确认它修的是另一个真实存在的问题(重建列表后位置没重算)。

顺带的清理(回答老师"砍偏的地方有没有影响"):
  · 拦 touch / 关捏合 / 吞补发 click 三刀早已回退或删除,代码里没有残留 ✓
  · 画布 touch-action:none 与 touchmove 的 passive 保留(前者是标准做法且不碰缩略图条,
    后者比原来更正确)✓
  · 唯一还带隐患的是滚轮那个非 passive 监听器:与 touchmove 那个坑同源
    (document 上非 passive 会让浏览器丢掉"不等 JS 就绘制"的快路径)。
    它的 preventDefault 其实是多余的 —— stopPropagation 就足以拦住控件的滚轮缩放
    (控件是在它自己的监听器里做的)。故一并改成 passive。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 11:58:10 +08:00
mole404 50d4d034ae fix(viewer): 包一层 update(),让缩略图条重建后补算位置(Claude 定位 / 已核对产物)
现象:看图时底部缩略图条偶尔空白;等多久都不出来,但手指一碰/一滑它立刻显示;
安卓和电脑端都有(所以不是之前猜的"安卓绘制快路径",那条成因已被证伪)。

机制(Claude 定位,我在源码与线上压缩产物里逐条核对过):
  viewer.update() 会把 .viewer-list 的 width 设成 auto、重建所有 <li>,但当前图没变时
  不调 renderList(),于是位置(width + translateX((容器宽-30)/2 - 31*index))仍是旧值。
  两者错配 ⇒ 列表盒子沉在屏幕左侧外面,只剩一条空黑底。手指一滑走 goTo→view→renderList,
  位置被重算,缩略图立刻回来 —— 与老师"一碰就出来"完全吻合。
  看图时触发 update() 的路径:images.blade.php 里无限滚动每次请求结束的 complete 回调
  (看图时后台正好加载完一批),以及侧栏折叠。所以是"偶尔"。

本机 A/B 实测(副本站,1280x720,第 35 张,80 个缩略图):
  A 组(线上那版):打开后量到 width=auto + translateX(-460px) —— 正是那个错配状态,量到了 ✓
  但没有复现将整条推出可视区(该尺寸/该张数下缩略图仍可见)⇒ 没敢声称"一定治好"。
  已如实说明。"一碰就好"这条证据与机制吻合,且本改动只把状态修对、不会变坏。

实现(不依赖可能被压缩改名的成员:产物里查不到 items / isShown,故改成查 DOM):
  · 包一层 viewer.update:跑完补一次 renderList(),并按 index 补回丢失的 li.viewer-active。
  · 守卫:update/renderList 不是函数就安静退出;整个补算包在 try/catch 里 ——
    补这一刀绝不能反过来把看图界面弄挂。
  · 注意这是 fork 侧自证:Dockerfile 钉的 images.blade.php md5 必须同步。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 11:07:55 +08:00
mole404 73bf20143b fix(viewer): 修上一版引入的回归——缩略图条在安卓上偶尔空白(非 passive 的 document touchmove)
老师报的现象:安卓上看图时,底部缩略图条偶尔不显示;**等多久都不会自己出来,
但手指一碰它立刻显示**,像被什么卡住了;大图始终正常;且「这个版本加了滚动才开始有」。

定位:这就是典型的「不重绘」。上一版为了让缩略图条支持拖动切图,在 document 上注册了
一个 **非 passive 的 touchmove**(还带了 preventDefault)。在 document 上注册非 passive 的
touchmove 会让 Chrome 失去「不等 JS 就滚动/绘制」的快路径 —— 表现为远离手指的元素
(屏幕底部的缩略图条)不重绘:一直空白,直到下一次触摸才画出来。安卓上尤其明显;
大图在屏幕中间所以看起来正常。全中。

修法:把它改成 **passive: true** 并去掉 preventDefault ——
缩略图条本来就是 touch-action:none、浏览器根本不会滚它,所以 preventDefault 是多余的,
去掉它对功能毫无影响(拖动切图逻辑一行没动)。注释里写明了"这里必须 passive,不许改回去"。

本机 9 套 jsdom 测试 409 项全绿(含拖动切图的行为用例)。
2026-10-03 10:45:11 +08:00
mole404 1eb6a54053 feat(viewer): 底部缩略图条上的快捷切图(电脑滚轮切一张 / 手机拖动连续切)
老师的两个诉求:
  · 电脑:光标在底部缩略图条上滚轮 ⇒ 快速前后切图
  · 手机:在缩略图条上左右拖动 ⇒ 连续滑动切换(不是"划一下才切一张")

实现(全部挂在外面,不改 viewer.min.js):
  · 滚轮:document 捕获阶段接住 —— 控件自己在外层容器上绑了"滚轮缩放"(也是捕获阶段),
    所以必须比它更早,并且只对落在 .viewer-navbar 上的滚轮生效:图上滚轮照旧是缩放。
    节流 260ms,滚一格切一张。stopPropagation 阻止它被当成缩放。
  · 拖动:tracker 在触摸起手记下起点与当时的 index,touchmove 里按"已滑过距离 / 40px"
    连续 follower —— 拖回来也会切回去,是连续跟随而不是一次性触发。
    另:缩略图条被库设成 touch-action:none、本来就划不动,所以不存在"抢走它自己的滚动"
    这个问题(它是靠自动跟随当前图工作的)。
  · 一律调对外 API viewer.view(index),到头即止(loop 已关)。

本机验收(模拟环境,1280x720,40 张缩略图):
  ① 缩略图条上滚一格 → 切到下一张 ✓
  ② 大图上滚一格 → 只有缩放、不切图 ✓
  ③ 缩略图条上往左拖 120px → 连续切过 3 张 ✓
  ④ 再往右拖回 80px → 能切回来 ✓
  无 JS 报错 ✓

顺带修的守卫冲突:
  · 注释里写了"调公开 API"撞上项目铁律「公开/私有 口径一个字的残留都不许有(含注释)」,
    改成"对外 API"。
  · tag-feature 的守卫 `!/viewer\.view\(/` 原意是"不许劫持卡片点击",收窄为
    "卡片点击附近不许出现 viewer.view(",并写明理由(新功能挂在缩略图条上,不碰卡片)。
  jsdom 9 套 409 项全绿。
2026-10-03 10:16:05 +08:00
mole404 f1fc0fd639 fix(viewer): 关掉到头绕回(loop:false)+ 收口双击判定(300ms 窗口、拖动不算轻点)
一、到头绕回(老师明确不需要循环)
   打开第一张图后向右滑"上一张",库会绕回最后一张;而这一下会让控件重建画布/缩略图条,
   随之出现两个现象:iOS 上整个看图界面左偏、右侧空出一条;安卓上底部缩略图全空(只剩框)。
   采用 loop:false 从源头去掉这个动作;若后续仍观察到错位/缩略图异常,再按"重建那一步"单独查。

二、双击判定的收口(老师反馈:连续拖动两下也被当成双击放大)
   库的「模拟双击」(handlers.js:424-451)只看两次抬手的间隔(硬编码 500ms,且改不了),
   完全不检查中间有没有拖动。在外面收口(不改 viewer.min.js):
     · 抬手时用「起点→终点」位移判断是轻点还是拖动,阈值 30px ——
       依据是实测:真滑动 130~300px(中位 214px),轻点抖动一般 <15px,30px 把两者分开;
       (老师提醒过 10px 太严,会误伤真双击,故取 30px。)
     · 是拖动 ⇒ 立刻清掉库的 imageClicked,拖动永远不能充当"第一次轻点";
       若这一下之前已有"第一次轻点",那发 50ms 后要派发的合成 dblclick 也一并拦掉。
     · 两次都不动的轻点 ⇒ 真双击,放行;并按老师要求把有效窗口从 500ms 收到 300ms。
   仍用 touchstart/touchend 的坐标差(不用 touchmove —— 安卓上它可能收不到)。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 02:13:47 +08:00
mole404 8eda125810 chore(viewer): 撤掉临时诊断(面板 + 打点)与「吞补发 click」那段无效补丁
问题已由 5f36036 的「松闩」修复解决,随之清理两处临时/无效代码:

1. 删除 `?dbg=1` 诊断面板与远程打点(整块临时代码,共 6.5KB)——
   定位结束后按约定撤掉,线上恢复干净。
2. 删除「吞掉滑动手势后 900ms 内的 click/dblclick」那段。
   它针对的是「凭空 dblclick 触发放大」这条**错误判断**(真因是 others.js 的闩锁),
   而且它有副作用:滑完图 900ms 内真双击会失效,与「保留双击放大」的诉求相冲突。
   真机上也从未验证过它有效,故一并移除。

保留:
- 5f36036 的松闩修复(真因修复,已在 jsdom 复现脚本上验证对比)。
- common.less 里给 .viewer-canvas / img 补的 `touch-action: none`
  (全屏看图控件的标准做法,零副作用,顺带避免浏览器中途收走手势)。
- viewer.min.js 始终未改动。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 01:45:47 +08:00
mole404 5f3603658b fix(viewer): 松开关闭切图手势的「闩锁」——这解释了安卓上「纹丝不动 / 大多数切图失败」
真因(真机打点 518 条 + 源码逐行核对 + jsdom 复现三方对齐):

  node_modules/viewerjs/src/js/others.js:216-223  change() 里

      case ACTION_SWITCH: {
        this.action = 'switched';                                   // ← 先上闩
        const absoluteOffsetX = Math.abs(offsetX);
        if (absoluteOffsetX > 1 && absoluteOffsetX > Math.abs(offsetY)) {
          … this.view(index);                                       // 过了判定才真切图
        }

  第一次 pointermove 进来就把 this.action 改成字符串 'switched',而外层 switch 没有这个分支
  ⇒ 之后每一次 pointermove 全部落空:不切图、不平移、不放大 = 用户看到的「纹丝不动」。
  判定只看开头那次采样,而真手指刚落下天然带纵向抖动(dy ≥ dx 很常见)⇒ 大多数手势一开始
  就被闩死,偶尔开头偏横向才成功 = 「大多数失败、少数成功、无规律」。iOS 上因为触摸路径不同
  不触发,官方演示页也没有列表页那套前置条件,所以都正常。

修法(不改 viewer.min.js —— 压缩产物改了没法维护):从外面把闩松开。
手势期间用 document 捕获阶段监听 pointermove,发现 viewer.action 变成了那个闩值,
就恢复成手势开始时 Viewer 自己算出的动作值;后续采样继续参与方向判定(判据看的是最近一次
位移,所以横滑终究会切到)。首次遇到闩值时自动学出「切图动作」的真值,无需硬编码常量。

验证(用 Claude 提供的 jsdom 复现脚本,加/不加本补丁对比):
  修复前:starts diagonal dy>dx, then horizontal → no switch        ✗
  修复后:starts diagonal dy>dx, then horizontal → SWITCHED         ✓
  对照组:vertical drag (should NOT switch)      → 仍 no switch     ✓(未被破坏)
  其余 7 个用例修复前后都正常。jsdom 9 套 409 项全绿。
2026-10-03 01:34:09 +08:00
mole404 36245c583b fix(viewer): 安卓切图失败的真因修复——看图控件自己"模拟双击",用抬手坐标差把它拦住
真机打点(420 条,会话 palh0x,老师只做了点开图片 + 左右滑动)暴露了真因:
  类型计数 pointerdown 102 / touchstart 102 / pointerup 102 / touchend 88 / click 3 / **dblclick 23**
  —— 老师没做过任何双击,却凭空出现 23 次 dblclick(且 click 只有 3 次,说明不是"两次单击拼出来的",
     而是被合成派发的)。

源头在库自身:`viewerjs/src/js/handlers.js:424-451`
    // Emulate click and double click in touch devices to support backdrop and image zooming (#210).
    if (IS_TOUCH_DEVICE && action !== ACTION_ZOOM && pointer && (Date.now() - pointer.timeStamp < 500)) {
      if (options.toggleOnDblclick && this.viewed && event.target === this.image) {
        if (this.imageClicked) { …dispatchEvent(this.image, EVENT_DBLCLICK, {…}) }   // ← 凭空派发 dblclick
        else { this.imageClicked = true; … }
即:**两次落在图片上的抬手间隔 <500ms**,它就自己派发一个 dblclick ⇒ 触发放大 ⇒ 图片不再
"刚好一屏" ⇒ isSwitchable 为假 ⇒ 滑动变成平移 ⇒ 大多数切图失败。老师连续快速滑图正好满足。

上一版(3ea41b9)为何没拦住:它靠 touchmove 判断手指挥动过,但安卓上控件在指针处理里
preventDefault 之后 touchmove 可能根本收不到 ⇒ moved 永远为 false。
本次改为用 **touchstart / touchend 的坐标差**(真机打点里这两种事件 100% 都有,已逐条核对),
位移 >10px 即认定是滑图,吞掉其后 900ms 内落进看图区域的 click/dblclick;
真正的双击是两下不动的轻点,不受影响 —— 老师要求保留的双击放大照旧可用。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-03 00:29:21 +08:00
mole404 3c05072fd8 debug(viewer): 诊断面板改用「远程打点」——数据直接落进服务器访问日志,并自动停在最新一行
老师反馈:面板设了 pointer-events:none 之后自己也不能滚动了,看不到最下面。改为更聪明的方案:
  1. 页面把每条事件打点回站点(fetch 到 /dbg-<会话号>/<序号>/<记录>)——请求会落进服务器
     访问日志,阿罗娜在远程直接读日志即可拿到全部数据,老师不需要截图、不需要滚动。
     打点只在 ?dbg=1 时发生(整块诊断代码都不带参数时不加载)。
  2. 面板加自动滚动,始终停在最新一行。

本机验证:带 ?dbg=1 打开并操作后,在服务器日志里读到了完整打点,含会话号与序号,例如
  dbg-2tuzt1/1/pointerdown img ptrId=2/touch @195,247
  dbg-2tuzt1/2/touchstart  img touchId=0 @195,247
  dbg-2tuzt1/5/click       img ptrId=2/touch @195,247
共 10 条。不带 ?dbg=1 时面板与打点都不出现。
2026-10-03 00:17:38 +08:00
mole404 3ea41b940d fix(viewer): 安卓触摸手势修复——吞掉"滑完图之后"补发的 click,画布补 touch-action:none
真机诊断数据(老师安卓 + ?dbg=1 面板)确认了两件事:
  1. 计数里 dblclick×5,且 .viewer-move 上出现 dblclick ——「本来要双击才放大,点一下就放大」
     被数据证实:看图控件只绑 pointer 事件,安卓在触摸抬手后还会补发一发 click,
     它和紧接着的轻点挨得近,被浏览器拼成 dblclick ⇒ 误触发放大。
     iOS 上 fork 的长按补丁正好吞掉 iOS 抬手那发 click,所以只有安卓坏。
  2. touchstart×35 但 touchend×31、pointerdown×35 但 pointerup×31、pointercancel×4
     —— 有几次手势被浏览器中途收走(部分来自诊断面板自身滚动,面板已改 pointer-events:none)。

改动:
  a) images.blade.php:只吞掉「手指挥动过(位移 >10px)」之后紧跟的那发 click/dblclick。
     真正的双击是两下不动的轻点,不受影响 —— 老师要求保留双击放大。
  b) common.less:给 .viewer-canvas 与其 img 补 touch-action:none(库只在 .viewer-container
     上声明了,画布层仍是 auto)⇒ 浏览器不把手指判成滚动,不再发 pointercancel。
  c) 诊断面板加 pointer-events:none,避免它自身滚动产生干扰。

本机验收(安卓 UA 模拟,重建 CSS 后):
  单击不放大 ✓;双击仍放大(351 → 3050)✓;画布 touch-action=none ✓;无 JS 报错 ✓;
  100/160/260px 三条滑动全部切图 ✓;两指捏合仍可用(351 → 1193)✓;jsdom 9 套 409 项全绿 ✓。
注:本机模拟仍复现不出该 bug,最终效果以安卓真机为准。
2026-10-03 00:05:51 +08:00
mole404 57714aa09a fix(debug): 诊断面板去掉 hover:none 字样,避免撞上「触摸端媒体查询已删」的守卫测试
images-modal.test.mjs 里有一条守卫:blade 代码(去掉注释后)不得再出现 `hover: none`
字符串(为了让触摸端操作按钮常显、不留无用/矛盾规则)。诊断面板里那句
`matchMedia('(hover: none)')` 正好命中该断言,导致 CI 的 jsdom 测试失败、镜像未提升。
面板本来就是临时诊断,去掉这一项即可(ontouchstart / maxTouchPoints / pointer:coarse 仍在)。

本机 9 套 jsdom 测试 409 项全绿。
2026-10-02 23:43:35 +08:00
mole404 1ca7f96ad7 debug(viewer): 临时诊断读数面板(?dbg=1),用于定位安卓看大图手势问题
背景:安卓(Edge/Chrome)看大图时切图/放大/拖动都不稳,iOS 正常,官方演示页在老师安卓机上
也正常;本机 Chromium 模拟安卓复现不出(滑动/单击/双击/捏合/事件计数/pointers 全正常)。
老师补充的关键现象:「出问题的时候,本来要双击才放大,点一下图片就能放大」——像输入被重复投递。
既然本机复现不了,改为取真机数据。

做法:仅在网址带 ?dbg=1 时,在页面顶部显示一块读数面板(26vh,避免遮挡图片),实时显示:
  · 环境:UA 尾部、ontouchstart、maxTouchPoints、hover:none、pointer:coarse
  · viewer 容器个数、大图尺寸 / 容器尺寸
  · 最近 20 条事件:capture 阶段的事件名 + 目标 + touchId/pointerId + 坐标;
    每条都跟一行 bubble 阶段的**最终 defaultPrevented**
  · 事件计数(touchstart/pointerdown/click/dblclick…)
点面板清空;不带 ?dbg=1 时完全不加载(已实测:不带时无面板 ✓,带时出现 ✓,计数实时更新 ✓)。

注意:这是**临时**代码,定位完即删除。
2026-10-02 23:39:23 +08:00
mole404 cc150e2f95 revert(viewer): 回退安卓触摸手势相关的两轮改动,恢复捏合缩放
前两轮都未获真机验证有效:
  05604dc 捕获阶段拦 touch* —— 实测 Viewer 只绑 pointer 事件,是空拦;且会挡住
          context-js 菜单守卫的触摸(点空白关菜单失效),属回归
  53edb1f 安卓关掉 zoomOnTouch —— 老师实测「还是不行」,与捏合无关
老师要求把捏合恢复,故把 images.blade.php / Dockerfile / patches/ios-longpress.patch
一并还原到 af7c730(老师验收「修得很完美」的那一版)。
md5 回到 27e13507a629aa3ae9f21496a6cf0ebf,zoomOnTouch 已移除(默认 true,捏合恢复)。

看大图手势的真因仍未定位。老师补充的关键现象:出问题时「单击一下图片就放大」(本该双击)
——即输入像被重复投递;但本机 Chromium 模拟安卓仍复现不出:滑动/单击/双击/捏合均正常,
一次单击只产生 1 个 click、双击是 2 click + 1 dblclick,只有一个 .viewer-container 实例。
下一步改为在页面加临时诊断读数,取真机数据定位。
2026-10-02 23:35:57 +08:00
mole404 53edb1ffb3 fix(viewer): 安卓上关掉「触摸捏合缩放」,绕开"单指被当成两指"的手势误判
现象:iOS 手机端手势完全正常;安卓(Edge/Chrome)看大图时切图极难触发、放大与拖动都不稳。
用户观感「单指被判定成双指」,与 Viewer 内部 `Object.keys(pointers).length > 1` 触发
ACTION_ZOOM 的表现一致。

已有的排查结论(都实测过):
  · 官方演示页在老师安卓机上正常 ⇒ 差异在我们自己的页面/环境,不是库本身在安卓上不能用
  · 本机 Chromium 模拟安卓复现不出来:两引擎、真手指速度、三种距离、hover:none、触摸+指针
    全量探针、touch-action 计算值链、pointercancel、页面滚动 —— 全部正常
  · 页面注册的 pointer 监听只有 Viewer 自己的(另一个是 Playwright 测试框架注入的)
  · Viewer 在触摸环境下绑的是 pointer 事件(实测 .viewer-canvas 上 pointerdown,
    document 上 pointermove/pointerup/pointercancel)
故不做无法验证的底层修补,改为**中和**这条误判路径:

    zoomOnTouch: !/Android/i.test(navigator.userAgent)

安卓上单指只可能被解释成平移/切图(放大仍可用工具栏 ± 与双击),iOS 行为完全不变。

同时撤掉上一版在捕获阶段拦 touch* 的代码:实测 Viewer 只绑 pointer 事件,那段是空拦;
且它会挡住 context-js 菜单守卫的触摸(点空白关菜单会失效),属回归,故删除。

本机验收(安卓 UA 模拟):100/160/260px 三条滑动全部正常切图 ✓;捏合缩放按设计在安卓关闭 ✓。
真机效果仍需老师在安卓上确认。
2026-10-02 23:24:13 +08:00
mole404 05604dcff2 fix(viewer): 安卓 Chromium 上看图控件触摸判定错乱 —— 拦掉重复的 touch* 事件流
现象:iOS 手机端手势完全正常,安卓(Edge/Chrome)看大图时切图极难触发、放大与拖动也常出问题。

真因(真 Chromium 实测的事件计数与 id):一次单指滑动同时收到 pointerdown ×1 与 touchstart ×1,
两者用的是**不同的 id 体系**(pointerdown: pointerId=5 / touchstart: touch.identifier=0)。
Viewer 的 pointerdown 里:

    if (options.zoomOnTouch && options.zoomable && Object.keys(pointers).length > 1) action = ACTION_ZOOM;

于是同一根手指被记成两个键 ⇒ 被判定成「两根手指捏合」⇒ 动作误派成 ZOOM,切图/平移都不对。
iOS 上两套 id 恰好同值(WebKit 的 pointerId 就是 touch identifier)⇒ 只有一个键 ⇒ 一切正常,
这正解释了为什么只有安卓坏。

修法:在看图容器那层用**捕获阶段**把 touch* 停掉,只留 pointer 一套(捏合缩放照旧走 pointer 路径)。
只影响 .viewer-container 内部,页面其它地方的触摸不受影响。

验收(本机模拟):一刀切图仍正常 ✓;两指捏合仍可用(图片宽 351 → 1193)✓;jsdom 9 套件全绿 ✓。
注:本机模拟复现不出该 bug(模拟器不是真安卓),但上面的事件计数与 id 差异是实测的,
实际效果请老师在安卓真机上确认。
2026-10-02 23:02:38 +08:00
mole404 af7c730edc fix(viewer): 用反向 zoom 根治看图控件在桌面 110% 缩放下的偏移
上一版只在「点开」这条路径上用 JS 重算 margin:键盘 ←→ 切图又偏回来,图片适配尺寸也偏大、
会盖住下方导航条 —— 逐条路径打补丁的方向是错的。

真因:<html>{zoom:1.1} 让 Viewer 内部「以为的 1px」只有屏幕上的 1/1.1。它按视觉尺寸
(window.innerWidth=1280)算居中/适配/边界,写出来的却是布局值(空间只有 1164),
渲染时浏览器又乘 1.1 ⇒ 居中偏、适配偏大、边界回收也错。

修法:在外壳上把缩放缩回去(common.less 的 html .viewer-container { zoom: calc(1/1.1) }),
让 Viewer 的子坐标系与屏幕 1:1,它自己的数学就全对;blade 里上一版加的 JS 补丁整块删除。
只在 @media (min-width:768px) 内,手机端零影响。

真机验收(生产库只读副本 + 一次性容器 + Chromium,1280×577):
- 图片视觉尺寸 = 布局尺寸(625.2 vs 625)⇒ 坐标系 1:1
- 画布高 577 = 屏幕高(原来 525)
- 左右留白差 +0.0(两张横图两张竖图都验过);按键盘 → 切图后仍 +0.0(上一版这里会偏)
- 图片底 455 / 导航条顶 525 → 留 70px,不再被下方按钮/缩略图压住
- 竖直:上 24 = 到工具栏间隙 24,对称(Viewer 主动给底部 UI 留位)
- jsdom 9 套件全绿
2026-10-02 22:34:10 +08:00
mole404 197a5f0cd6 fix(viewer): 桌面 110% 缩放下看图控件整体右偏 + 遮罩盖不满屏幕
真因(真 Chromium 实测,1280×577 / html{zoom:1.1}):
- 布局空间只有屏幕的 1/1.1(1280 屏 → 布局 1164)。Viewer 按「视觉屏幕宽 1280」算居中,
  算出的 margin-left 被当【布局值】写进内联样式 ⇒ 渲染时又 ×1.1 ⇒ 图片整体右偏
  (1280 − 1280/1.1)/2 ≈ 58 布局 px(渲染 64px)。实测左右留白 360.1 / 232.1(差 +128)。
- 看图外壳(.viewer-container,fixed + inset:0)在 zoom 下只铺到屏幕的 90.9%
  (1163.6×524.5),右侧/底部约 116×52px 的遮罩盖不住。

修法:
- blade:点开图后约 4s 内持续按【布局单位】重算大图 margin(幂等;z=1 的手机端直接跳过;
  带「整图适配」护栏,不干扰用户自己的放大/平移)。不用 Viewer 的事件 API —— 内置的
  viewer.min.js 是压缩产物、实例上没有可用的 .on()(用了会让整段脚本报错)。
- common.less:外壳改 width/height:100%(实测渲染出来正好铺满屏幕;不能用 100vw,
  zoom 下它会渲染成 1408 即溢出 10%)。

真机验收(生产库只读副本 + 一次性容器 + Chromium):
- 左右留白 296.4 / 295.8(差 +0.6)✓  上下 51.5 / 51.3(差 +0.2)✓
- 容器与遮罩 = 1280×577 = 正好一屏 ✓
- 手机档 390 宽:z=1,代码自动跳过,左右 19.5/19.5(差 0.0,与原样一致)✓
- jsdom 9 套件 409 项全绿 ✓  无 JS 报错 ✓
2026-10-02 21:17:39 +08:00
mole404 6e317b106a wip: 看图控件桌面 110% 缩放下居中(A 容器铺满已验证;B margin 重算已落地但仍有约 21px 残余,未完成) 2026-10-02 21:17:39 +08:00
mole404 462bd0d47c Revise installation steps in README.md
Updated installation instructions for clarity and added a step for post-installation usage.
2026-10-02 20:37:31 +08:00
mole404 d5263fcab3 Update README.md 2026-10-02 20:35:34 +08:00
mole404 cc67964c68 Update README.md 2026-10-02 20:35:09 +08:00
mole404 cdf512b289 Update README.md 2026-10-02 20:34:05 +08:00
mole404 a2a12f3fcf Update README.md 2026-10-02 20:33:51 +08:00
mole404 aa476b4d7f Update README.md 2026-10-02 20:33:02 +08:00
mole404 6239d69904 Revise README for clarity on features and changes
Updated README to clarify changes and features.
2026-10-02 20:31:19 +08:00
mole404 2847a533e2 Update README.md 2026-10-02 20:30:46 +08:00
mole404 d83bbc550f Update README.md 2026-10-02 20:28:54 +08:00
mole404 4a54f9ae7f Update README.md 2026-10-02 20:27:30 +08:00
mole404 c04861aeed Update README.md 2026-10-02 20:25:15 +08:00
mole404 a672b38a31 Update README.md 2026-10-02 20:23:22 +08:00
mole404 fcdbfef3f7 Revert "fix(css): 桌面 110% 缩放下看图控件整体右偏 —— .viewer-container 按 ls-zoom 口径除以 1.1"
This reverts commit 51fb29b767.
2026-10-02 20:21:12 +08:00
mole404 736c3f2d8f Update README.md 2026-10-02 20:17:35 +08:00
mole404 61f8b1cec5 Update README with new features and upgrade support
Added support for lossless upgrades from upstream Lsky-Pro V2.1.
2026-10-02 20:16:37 +08:00
mole404 99e6d2a741 Update README.md 2026-10-02 20:14:32 +08:00
mole404 beb1f6215b Update README.md 2026-10-02 20:13:26 +08:00
mole404 26bc434330 Update README.md 2026-10-02 20:12:09 +08:00
mole404 14ab830656 Update README.md 2026-10-02 20:10:43 +08:00
mole404 51fb29b767 fix(css): 桌面 110% 缩放下看图控件整体右偏 —— .viewer-container 按 ls-zoom 口径除以 1.1
Viewer.js 的 .viewer-container 是 position:fixed + inset:0 的「一屏大」盒子,
在 html{zoom:1.1} 下与 .min-h-screen 同理会渲染成 1.1 屏,而它内部由 JS 用布局单位
居中 ⇒ 图片整体向右下各偏 5%(1280 宽约 +64px),表现为「左键打开图片左右不居中」。
按既有 calc(100vh / 1.1) 同一口径把盒子宽高也除以 1.1,渲染出来正好一屏;
容器内 canvas / backdrop / footer 都是它的 inset:0 子元素,随之归位。
只写在 @media (min-width:768px) 内,手机端零变化。
2026-10-02 19:59:03 +08:00
mole404 bd61d24c8c Update README.md 2026-10-02 19:34:45 +08:00
mole404 2d6e6e13c1 docs(README): 挂载卷示例改为 $PWD/lsky-pro/data;更正 ~ 的说明(compose v2 会展开)+ 补 ./ 与 $PWD 的区别 2026-10-02 19:27:59 +08:00
mole404 a5bce095e2 fix(install): 安装向导默认数据库类型改为 SQLite;README 挂载路径改用 $PWD 2026-10-02 19:24:14 +08:00
mole404 8137ee1e04 fix(install): 安装向导默认数据库类型改为 SQLite;README 挂载路径改用 $PWD
两件事:
1) 安装向导(src/resources/views/install.blade.php)
   · 数据库类型的选项顺序:SQLite 提到第一个(= 浏览器默认选中),MySQL/PostgreSQL/SQL Server 保持原序。
     镜像自带 pdo_sqlite,开箱即用;README 第 55 行本来就写着「默认 SQLite」,这次把代码对齐文档。
   · 页面加载时主动触发一次 change:那个 change 处理器同时负责「按类型显示/隐藏连接字段」,
     不触发的话默认选中的 SQLite 旁边还挂着 MySQL 那套字段(127.0.0.1 / 3306 / root)与端口,
     看着像选错了,SQLite 的说明文字也不会出现。
   · tools/diff-vs-upstream.sh 的 KNOWN_DEVIATIONS 里该文件的理由补上这一条(文件本来就在清单里)。

2) README(只改文档,不动任何 compose 文件)
   · 挂载卷路径 /root/lsky-pro/data → $PWD/data(compose 片段)与 "$PWD/data:/var/www/html"(docker run 片段);
     仓库自带的 docker-compose.yaml 本来就用 $PWD/web 这套写法,风格统一。
   · 补一句提醒:compose 文件里别写 ~(不经过 shell 不会展开)。
2026-10-02 19:18:56 +08:00
mole404 7e3424059e feat: v3.2 —— 旧版/上游站点升级时自动补迁移(无需人工干预)
合并 test/v3.2-auto-migrate:
  · entrypoint 新增 auto_migrate():只读守卫 → 只补缺失迁移文件 → 真有 pending 才备份
    → 降权(www-data)跑 migrate → 任何失败只警告不挡启动(set -eu 下不许 exit);
    开关 AUTO_MIGRATE=0。此前从上游 v2.1 / 旧版镜像升级必须人工拷迁移文件 + 手跑 migrate。
  · 版本号 src/config/app.php:v3.1 → v3.2。
  · CI 真升级用例新增「4b 自动迁移用例」(默认跳过,本机 AUTO_MIGRATE_TEST=1 复跑)。

本机验证(生产库只读副本造的真 v2.1 卷,409 张图):补 2 个迁移文件 → 检测到 2 条 pending
→ 备份 → tags/image_tag 两张表 DONE,数据行指纹逐字节不变;坏配置缓存 / 半迁移状态都只警告不崩。
CI 真升级用例 1~4 段全绿(数据面逐字节相同)。
2026-10-02 17:38:53 +08:00
mole404 c07b18e95a test(upgrade): 自动迁移用例降级为「仅本机可跑」(AUTO_MIGRATE_TEST=1) 2026-10-02 17:34:01 +08:00
mole404 4cf737dd42 diag(entrypoint): 迁移改用绝对路径调用 artisan + 失败时自动打印诊断
CI 上那条 `runuser -u www-data -- sh -c 'cd /var/www/html && php artisan migrate --force'`
出现过「零输出 + 退出码 1」,而本机用同一条 CI 播种脚本复刻出的卷跑同样的代码却成功,
一时定位不到环境差异。这次:
  · 迁移改成 `runuser -u www-data -- php /var/www/html/artisan migrate --force`
    (artisan 自己按 __DIR__ 解析 base path,不必 cd,少一层 sh -c 的失败面);
  · 万一还是失败,失败分支会打印诊断:runuser 路径、php -v、artisan --version、
    卷里有没有 storage/logs、database/ 的属主与内容 —— 让日志自己说明原因。
2026-10-02 17:28:52 +08:00
mole404 3b74c8aae8 fix(entrypoint): pending 判定不走 Laravel(坏/外来的配置缓存会打死 artisan)
CI 第一次跑这个特性时红了,根因是一个真实存在的坑:
站点自己的 bootstrap/cache/config.php 一旦是坏的或外来的(CI 真升级用例里那个
**故意写坏**的哨兵文件就是),任何 artisan 命令都会报
`Target class [files] does not exist` —— 于是 migrate:status 读不到任何东西,
pending 被误判成 0,自动迁移静默不发生。

改法:SQLite 的 pending 判定改成**纯只读 PDO** 比对「盘上迁移文件」vs「记账表里的
行」,完全不经过 Laravel(连配置缓存都不读),因此对坏缓存免疫;其它数据库(MySQL /
Postgres)仍走 migrate:status(那类站点不会有本地 config 缓存文件这回事)。

顺带在 CI 用例的 4b 段里把那个哨兵配置缓存挪开:真站点的配置缓存要么不存在、
要么是有效的;它在前面那段是用来验证「同步不许覆盖站点自己的配置缓存」的,
两种用途不能混在一个卷上。

本机实测(拿生产库只读副本造的真 v2.1 卷,409 张图):
  · 干净卷 → 自动补 2 个迁移文件 + 检测到 2 条 pending + 备份 + 两张表 DONE,
    数据行指纹与升级前**逐字节一致**,容器退出码 0
  · 坏配置缓存仍在时 → 迁移如实报错、只打警告,容器照常启动(退出码 0)
  · 表在但记账行被删的半迁移状态 → 同样只警告不崩,下次启动自动重试
2026-10-02 17:20:44 +08:00
mole404 4d75333320 feat(entrypoint): 旧版/上游站点升级时自动补迁移 + 版本号升到 v3.2
背景:同步分支刻意排除 ./database(保护线上 SQLite),于是镜像里新增的迁移文件
永远进不了卷 —— 用户按 README 只做 `pull && up -d` 时新表不会出现(Nothing to
migrate)→ 新功能 500。此前「从上游 v2.1 / 旧版镜像升上来」必须人工拷迁移文件再手跑
migrate(2026-10-01 发标签功能时就是人工做的)。

现在 entrypoint 每次启动自动收尾,且处处以「不伤数据、不挡启动」为前提:
  ① 守卫先行:SQLite 走只读探测(file:...?mode=ro,不启 Laravel、不写库文件),
     其它库走 migrate:status;只认「有 migrations 记账表的真站点」,空卷/手搓库/非标
     安装一律跳过,绝不自作主张建表。
  ② 只补**缺失**的迁移文件(逐个判存在再 cp -p,绝不覆盖用户自己改过的那份)。
  ③ 真有 pending 才备份 SQLite 三件套(保留最近 3 份)再迁移 —— 没有 pending 就一句话
     结束,免得每次重启白备份一份库。
  ④ 一律降权到 www-data 执行(root 跑会把 -wal/-shm 造成 root 属主 → 站点写不进库)。
  ⑤ 任何失败只打日志、绝不 exit:本脚本 set -eu,非 0 冒泡出去容器就起不来(配合
     restart: unless-stopped 即无限重启)。失败时下次启动自动重试。
  开关:AUTO_MIGRATE=0 关闭(默认开)。

CI:tools/upgrade-test.sh 新增「4b) 自动迁移用例」——构造真 v2.1 形状的卷(migrations
记账表里只有上游 10 条 + 卷里没有那两个 fork 迁移文件),重启新镜像后断言:迁移文件被
自动补进卷、tags/image_tag 自动建好、记账涨到 12、**哨兵数据指纹逐字节不变**、迁移前
自动备份存在。

版本号:src/config/app.php 的 fork 版本串 v3.1 → v3.2。
2026-10-02 17:12:56 +08:00
mole404 74023534bc Update README.md 2026-10-02 16:54:17 +08:00
mole404 230387d880 Update README.md 2026-10-02 16:54:00 +08:00
mole404 4be06451cb Update README.md 2026-10-02 16:52:27 +08:00
mole404 de527c3ecb ci: 纯文档推送不再触发完整构建(paths-ignore)
此前任何 push 都会跑一遍完整构建:约 10 分钟 runner + 一个约 1GB 的新镜像版本
(GHCR 版本堆到 100+ 个的主因),改个 README 也会把 :latest 顶成新 manifest ——
而镜像只 COPY src/ + 3 个 *.template + entrypoint.sh,README 并不进镜像,应用内容一字未变。

只忽略不进镜像、也不被构建/自证读取的文件:**.md、LICENSE、.gitignore。
语义是 fail-open:只有本次推送的改动全部命中忽略列表才跳过;碰到任何代码文件照旧构建。
2026-10-02 16:40:44 +08:00
mole404 437b788cb5 Update README.md 2026-10-02 16:37:41 +08:00
mole404 e2f0b0e2bd ci: 加一个手工触发的 GHCR 旧版本清理工作流
每次构建都会留下一个不可变的 sha-<commit> 版本(约 1GB/个),堆多了 GHCR 页面很乱、
回滚时也容易看错目标。这个 workflow 只在手工触发时运行:
默认 dry=true(只列出计划不删),清理时也永远保留 latest 与最近 N 个版本。
2026-10-02 16:29:34 +08:00
mole404 711759331d Update README with improved clarity and details 2026-10-02 16:16:58 +08:00
mole404 6e9b60635a Update README.md 2026-10-02 16:04:17 +08:00
mole404 5bfdd62d0e Update README.md 2026-10-02 16:03:55 +08:00
mole404 c8b1242c59 Update README.md 2026-10-02 16:03:11 +08:00
mole404 efbfce99e7 Update README.md 2026-10-02 15:45:58 +08:00
mole404 f64d55a905 Revise features section in README.md
Updated feature list and improved clarity on backup and versioning.
2026-10-02 15:36:30 +08:00
mole404 9980ba3efc Update README.md 2026-10-02 15:35:42 +08:00
mole404 25af68f44a release: 图库标签功能正式版(含界面改造、框选修复与一轮代码审查修复)
master 之前停在 596e81a(上一位维护者的最后一次改动)。本次把 test 分支整体并入,
作为正式版发布:

- 新功能:图片标签(打标 / 批量打标 / 按标签筛选 / 卡片角标,按用户隔离)
- 界面:整套前端重做之后的收尾迭代(图库工具栏、标签窗口、开关、对齐等)
- 修复:框选选择框与判定框对齐(含 html zoom:1.1 下的坐标错位)、原生拖拽、
        缩放下的命中判定
- 下线:图片权限(公开/私有)的界面临口(数据列保留,接口行为不变)
- 代码审查修复 6 条:改名/删标签不再清空选中、删图片/删用户清理中间表、
        data-json 转义、接口错误提示、标签名先 trim 再校验、硬编码路径改 route()
- 文档:README 重写为项目介绍优先
- 测试:jsdom 118 项 + 真机验收 70 项全绿;新增标签数据完整性自检脚本

发布方式照旧:本次 master 构建通过镜像自证后,CI 才会把 :latest 指过来。
2026-10-02 15:13:11 +08:00
mole404 1f1b2bdf59 docs(readme): 重写为「项目介绍优先」—— 先说这镜像能给你什么,再放关键细节
保留的关键细节:快速开始(compose / docker run)、首次安装、升级与「钉版本」用法、
备份为什么要整卷(WAL)、哪些是数据哪些是可替换代码、端口与并发参数表、
与上游的关系与自查方式(diff-vs-upstream.sh / check-tag-integrity.php / test)、
许可与致谢(上游 GPL-3.0、打包脚本 AGPL-3.0)。
新增「这个镜像能给你什么」一节,把标签功能、界面、加固、低配友好这些卖点摆到前面;
补充 latest 与 sha-<commit> 的发布策略说明(只有 master 的构建通过自证才会推进 latest)。
2026-10-02 15:12:59 +08:00
mole404 c242bfb12c fix(tags): 代码审查发现的 6 条问题全修 + 补真机/静态断言
审查(含新加的打标部分)发现并修掉:
1. 改名/删除标签会清空选中 ✗ —— refreshAfterTagChange() 走 setTags() → resetImages(),
   会清空图片墙并 ds.clearSelection(),把用户正在打标的这批图连同弹窗勾选态一起丢掉
   (老师问过的「编辑/删除会整页刷新」)。改为 patchCardsTag() 就地同步(卡片角标 + data-json
   + 详情卡 chip);只有「被删的标签正用作筛选项」这种结果集真的变了的情况才调 setTags()。
2. 删图片/删用户不清 image_tag / tags ✗ —— 两个迁移的注释都写着「关联行由应用代码显式删除」,
   图片这条路径没落实,残留行会无声累积。UserService::deleteImages() 补 detach();
   后台删用户时一并清标签与关联行。(本机 SQLite 未启用 PRAGMA foreign_keys,不能指望级联。)
   附带 tools/check-tag-integrity.php:只读自检残留行,退出码非 0 即为异常。
3. 标签名进 data-json(单引号属性)未转义 ✗ —— 名字里带 ' 就能提前闭合属性(自伤型 XSS 面)。
   三处注入(列表渲染 / 弹窗行 / syncCardTags)统一先 escapeHtml 再写。
4. 弹窗里几个 axios 调用没有 catch ✗ —— 网络错误或 422(名字超 64 字)会静默无反应。
   统一走 apiErrMsg() 取后端 message;三个标签名输入框补 maxlength=64。
5. 后端 trim() 在校验之后 ✗ —— 只输入空格会建出空名标签。TagRequest 加 prepareForValidation()。
6. 两处硬编码路径 ✗(action="/user/tags/__id__"、axios.delete('/user/tags/'+id))→ 改用 route()。

测试:
- jsdom 118/118(新增 7 条:改名的局部同步、data-json 转义、maxlength+catch、
  deleteImages/删用户的清理、TagRequest trim;测试台补 renderTagRoutes 渲染带 id 的路由)。
- 真机 70/70(新增 #2c:改标签名后选中不丢 / 图片墙不重载 / 角标就地换名,
  6 项断言,在整轮末尾单开 context 跑,避免本机 1vCPU/965MB 下的页面 OOM)。
- 真机实证:图片挂 1 条关联 → deleteImages → 残留 0;check-tag-integrity.php 干净 ✓。
- tools/diff-vs-upstream.sh:已知偏离清单补登 UserService.php / Admin\UserController.php,
  校验通过(103 项,恰好等于实际偏差)。
- patches/ios-longpress.patch 按原范围(3 个文件)重新生成。
2026-10-02 14:59:40 +08:00
mole404 64dc93be5b fix(images): 框选判定改由原始指针坐标驱动 —— 修掉"框住上一行、下一整行被选中"
真因(实测):页面是「<html>{zoom:1.1} + 整页滚动」。DragSelect 内部把**布局单位**的滚动量
混进了**视觉**指针坐标,于是它算出的判定框 = 真实框 ×1.1 + 随滚动增大的偏移
(滚动 670 时约 (28,−55);误差 ≈ scroll×(1−1/zoom),所以"不滚动就不偏")。
它的 zoom 选项只影响尺寸、不修指针坐标 —— 喂 zoom:1.1 也没用(实测照旧)。
结果:框住上面那行、下面一整行却被选中,框越大偏得越离谱。

修法:
- clientX/clientY 与 getBoundingClientRect() 同属视觉坐标 —— 按原始指针路径自己记框,
  ① 覆盖 ds.Selector.rect 给库判定用 ② 每帧把屏幕上的框摆到同一处
  (外壳 .ds-selector-area 按区域矩形铺满,框是它的子元素、坐标必须相对区域原点)。
- 指针事件必须注册在**捕获阶段**:库在 mousedown 冒泡阶段就做判定,晚注册的话
  它那一刻读到"还没开始的空框" → 单击卡片不勾选(实测 0 张)。
- 删掉上一版的"手工除以 zoom 再写回"补偿。那是第二个补偿,与库自己的算法打架;
  更糟的是它的 rect 覆盖读的是库刚写进元素的矩形 —— 等于把错误读两遍,
  验收因此一直是绿的(这次把验收也改成真正的判据,见下)。

保留:图片墙排完版后 ds.Interaction.init() 重测 + 清掉库的缓存矩形("拖不动"的老根因)、
      原生拖拽抑制(-webkit-user-drag + dragstart)。

验收(这次不再自我循环):
- 真机 64/64。新增 #2b「诚实框选」在滚动 0/240/670 各验一遍:
  ① 画出来的框 == 库拿去判定的框 ② 鼠标坐标与页面 clientX/Y 同一套(证明测试本身可信)
  ③ 逐张比对"几何上该不该选中"与实际选中,必须完全一致。
  —— 上一版就是缺 ③,才让"假绿"混过去。
- jsdom 111/111。
2026-10-02 14:08:10 +08:00
mole404 bab875aeda fix(images): 缩放倍数改用「布局÷视觉」比值(修老师环境里极大的拖选偏移)+ 撤回过度下压
1. 老师环境里拖选偏移极大(框住上一行、下一整行被选中,误差半个行高以上),我这边量不出来 →
   锁定为**浏览器页面缩放**:原来 dsZoom() 读 getComputedStyle(html).zoom,浏览器自身的页面缩放
   可能被折进这个值里,导致除以一个偏大的倍数、整个盒子在页面上跑偏。
   改成用「布局尺寸 ÷ 视觉尺寸」的比值算(只由 CSS 的 html{zoom:1.1} 决定,页面缩放不影响它)。
   实测:默认比值 1.0999、注入 zoom=1.25 时比值 1.2500,两种情况下「判定框 == 画出来的框」误差都是 0.00px。
   新增 jsdom 静态断言:必须用比值、禁止再读 getComputedStyle 的 zoom。
2. 「显示图片标签」那一行:上一轮按 canvas 字体度量把文字下压了 1.5px,实为压过头
   (改成**截图像素法**量:文字比行中心低 1.49px,所以看着开关偏上)→ 撤回下压,
   现在文字/开关都在行中心 ±0.3px 内。验收脚本 #5b 也从「字体度量」改成「截图像素」量。
3. 菜单里「暂无标签」空态行 py-4 → py-2(比别的菜单行厚一倍,整块看着偏下)。

验收:jsdom 110/110(标签那份)、全仓 396;真机 61/61 全绿。
2026-10-02 12:29:44 +08:00
mole404 c1ab184b83 fix(ui): 标签开关收小 + 那一行墨迹居中 + 策略页角色组多选框加高
按老师第三轮反馈(4 条里的 1/2/4,第 3 条另查):
1. 开关收小一点点:18×32 → 16×28(滑块 14 → 12,行程 14 → 12),保持两态形状一致。
2. 「显示图片标签」那一行上下不居中:量出来文字**墨迹**中心比行中心高 1.5px(字体上下墨迹天生
   不对称),旁边放个居中的开关就显出来了 → 文字下压 1.5px,实测墨迹 239.32 vs 行 239.18(+0.14),
   开关 +0.49,两者互相对齐。
4. 存储策略编辑页的「选择角色组」多选框默认只有两行高(form-multiselect 在上游样式表里其实
   不存在,等于没给高度)→ 显式 min-h-[8rem],实测 128px(5~6 行)。

验收:jsdom 全仓 396;真机 61 条全绿(新增 4 条:墨迹居中、开关与墨迹对齐、开关尺寸、多选框高度)。
第 3 条(滚动后纵向偏移)另附排查结论:滚动 0/300/600/900 四档实测「画框 == 库判定框」误差 0px、
被选中卡片加入瞬间均与框相交,怀疑是卡片盒子比可见图片外扩 10px(justified-gallery border:10)
造成的「擦边就选中」,等老师做一个小实验确认。
2026-10-02 11:54:02 +08:00
mole404 6e3a0428f1 fix(images): 框选判定矩形接实时位置(纵向偏移)+ 自己画「显示图片标签」开关
1. 拖选纵向偏移的真因:库把选择框的判定矩形缓存成 clientWidth × zoom,在缩放文档里既比实际
   大 1.1 倍、纵向还随页面滚动跑偏(实测滚动 0 偏 (20,14)、滚动 500 偏 (18,63)),于是「框住上面
   这行」把下面一行也选了。修法:把 ds.Selector 的 rect 接到 .ds-selector 的实时矩形上 ——
   判定区与画出来的框永远重合(真机验收:滚动 0/240/500 三档,四边误差 < 3px)。
2. 「显示图片标签」开关改成自己画的(老师选的第 3 案):圆角药丸 + 滑块,两态形状完全一样,
   只变颜色与滑块位置(开=bg-brand 滑块靠右、关=bg-line 滑块靠左),不再用 FontAwesome 的
   fa-toggle-on/off(那两个字形一粗一细)。

验收:jsdom 全仓 396(标签那份 109/109);真机 57/57 全绿,其中 #4b 新增 6 条专门盯纵向偏移
(每档都比对「库判定框 vs 画出来的框」,并按「加入瞬间是否真的相交」核对每一张被选中的卡片)。
2026-10-02 03:13:20 +08:00