点开是下载或404，因href指向的小图路径非真实大图URL；正确做法是href必须链接到独立存在、可访问的高分辨率大图文件（如href="large.jpg"），且服务器需正确配置MIME类型与路径。
用 <a> 包裹 <img> 点击跳转到大图，为什么点开是下载或 404？
因为默认行为是「跳转到 href 指向的 URL」，但如果你把原始小图路径直接塞进 href（比如 href="thumb.jpg"），浏览器会尝试加载同一张小图——不是放大，更不会自动变大；如果服务器没配好 MIME 类型，还可能触发下载；路径写错则直接 404。
真正能“点击放大”的本质，是让链接指向一张**分辨率更高、独立存在的大图文件**。不是靠 HTML 自动缩放，而是换图源。
-
href必须指向一个真实可访问的大图 URL，例如href="large.jpg"，且该文件需实际存在、HTTP 状态码为 200 - 小图（
<img src="thumb.jpg">）和大图（href="large.jpg"）应保持语义对应，建议命名规则统一，如photo-1-thumb.jpg/photo-1-large.jpg - 不要复用同一张图的路径——除非你明确希望用户在新页打开原图（此时只是查看原尺寸，非“放大”体验）
纯 HTML + CSS 能否不跳转、只在当前页放大？
可以，但必须放弃 <a> 的默认跳转行为，改用 CSS :hover 或配合 data-* 属性 + 简单 JS 控制显示层。纯 HTML + CSS 无法实现点击后居中模态框+遮罩+缩放动画，那需要 JS 参与状态管理。
最轻量的非跳转方案：用 <details> + <summary> 模拟点击展开（兼容性好，无需 JS）：
<details> <summary><img src="thumb.jpg" alt="缩略图" width="200"></summary> <img src="large.jpg" alt="大图" style="max-width: 90vw; margin: 1em auto; display: block;"> </details>
- 点击
<summary>展开大图，再点收起，无跳转、无新页面 - 缺点：不居中、无遮罩、无过渡动画；iOS Safari 对
<details>的样式控制较弱 - 若需居中/遮罩/关闭按钮，就必须用 JS 监听
click，动态插入<div class="modal">并设置background-image或替换<img>的src
用 lightbox 类库时，<a> 的 href 和 data-src 有什么区别？
主流 lightbox（如 Lightbox2、fslightbox、SimpleLightbox）都依赖 <a> 标签作为触发器，但它们不直接用 href 显示图片——而是读取自定义属性，避免干扰 SEO 和基础可访问性。
-
href应始终指向大图 URL，确保无 JS 时仍可跳转查看（降级可用） -
data-src（或data-large）是类库实际读取的放大图地址，常用于支持响应式多图源（如 WebP / AVIF） - 部分类库要求
href="#"+，这是反模式：破坏了语义和降级能力，慎用 - 务必检查类库文档对属性名的要求，例如 fslightbox 用
data-fslightbox，而 SimpleLightbox 默认读href
移动端点击放大图片，为什么手指松开才触发，感觉卡顿？
这是 iOS Safari 和部分安卓浏览器对 click 事件的 300ms 延迟导致的——它等待判断是否为双击缩放，造成点击反馈滞后。解决方案不是加 JS 判断，而是从事件源头规避：
- 给
<a>添加ontouchstart=""属性（空字符串即可），可提前激活 tap 行为，消除延迟 - 或者用
touchend替代click绑定 lightbox，但需自行处理preventDefault()和点击穿透问题 - CSS 层面加
cursor: pointer和-webkit-tap-highlight-color: transparent提升触感反馈 - 注意：不要在
<img>上直接绑定 touch 事件——父级<a>才是语义正确的交互目标
实际部署时最容易被忽略的是大图资源的加载时机和尺寸标注。很多开发者以为只要 href 正确就万事大吉，结果用户点击后白屏几秒——因为大图未预加载、也未设置 width/height 导致布局偏移。建议在 <a> 上加 data-width 和 data-height，lightbox 初始化时可据此设置容器尺寸，避免闪动。
