应使用语义化的 + 组织单幅作品，配合 css grid 实现响应式画廊，用 srcset+sizes 提供多尺寸图片，并优先采用原生 实现点击放大。
用 <figure></figure> + <figcaption></figcaption> 组织每张作品，别用 <div> 堆砌
<p>纯靠 <code><div> 包图加文字，后期维护、语义化、SEO 和屏幕阅读器支持全都会出问题。浏览器和辅助技术靠 HTML 语义识别“这是一张带标题的摄影作品”，<code><figure></figure> 就是为此设计的。
实操建议：
- 每张作品独立用一对
<figure></figure>包裹，内部放<img>和<figcaption></figcaption> -
<figcaption></figcaption>放作品名、拍摄时间、地点或简短说明，别塞大段文字 - 避免把多个
<img>塞进同一个<figure></figure>—— 那属于图注组合（如对比图），不是单幅作品展示 - 如果需要响应式懒加载，直接在
<img>上加loading="lazy"，别额外写 JS
用 CSS Grid 实现等宽不等高画廊，避开 float 或 inline-block 的坍塌陷阱
摄影作品尺寸差异大，强行统一高度会裁切主体；用 float 或 inline-block 容易因换行、空白符导致布局错位，且难以控制列数响应变化。
实操建议：
- 给画廊容器设
display: grid，用grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))实现自动列数适配 - 每张
<figure></figure>设margin: 0和width: 100%，让图片自然撑满宽度 - 图片用
height: auto+max-width: 100%，保持原始宽高比 - 慎用
object-fit: cover—— 它会强制裁剪，可能切掉关键构图；仅在明确需要缩略图一致高度时局部启用
点击放大用原生 <dialog></dialog>，别急着上 Lightbox 库
多数轻量级作品集不需要完整 Lightbox 功能（如键盘导航、缩放、下载按钮）。用第三方库反而增加首屏体积、JS 执行延迟，还可能和现代 CSS 冲突。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操建议：
- 用
<dialog></dialog>标签包裹大图和关闭按钮，配合showModal()控制显隐 - 放大图用
<img>直接指向高清原图 URL（注意路径别写错成缩略图） - 为
<dialog></dialog>加backdrop-filter: blur(4px)提升视觉层次，但要测试 Safari 兼容性（iOS 16.4+ 支持） - 必须监听
click在 backdrop 上关闭，否则用户点背景无法退出 ——dialog默认不自动关闭
加载性能关键：用 srcset + sizes 按视口提供合适尺寸图
一张 5MB 的原图直接塞进移动端页面，首屏加载慢、流量浪费、甚至触发 iOS Safari 的图片降质策略。
实操建议：
- 准备至少三档尺寸：400px（小屏）、800px（中屏）、1200px（桌面）宽的 JPEG，质量调到 75–82
-
<img>上写：@@##@@
- 别依赖 CMS 自动生成的
srcset—— 很多系统只按容器宽度算，没考虑设备像素比（dpr），结果 Retina 屏仍加载低清图 - 用
<picture></picture>仅当需 WebP/AVIF 格式降级时才加，别为了“先进”而加一层嵌套
srcset 中 sizes 的值 —— 它不是固定写死的，得根据你 Grid 列数、间隙、边距实时计算，哪怕只差 10vw，也可能让高 DPR 设备加载错档位。
