@media (update: slow) 不是适配电子墨水屏的开关，而是系统级更新偏好信号；主流墨水屏设备（如Kindle、reMarkable）的定制系统不支持该CSS特性，浏览器也未对其做硬件感知，实际匹配率几乎为零。
@media (update: slow) 不是用来“适配电子墨水屏”的开关，而是系统级更新能力提示信号——它在绝大多数电子墨水屏设备上根本不会匹配，别把它当硬件探测器用。
为什么 @media (update: slow) 在墨水屏上基本无效
这个媒体特性检测的是操作系统报告的“内容更新偏好”，不是物理刷新率。主流电子墨水屏设备（如 Kindle、reMarkable、BOOX）运行的定制 Linux 或封闭系统，根本不实现 CSS update 媒体特性。Chrome、Safari、Firefox 桌面/移动版即使支持该特性，也仅面向 LCD/OLED 设备的功耗策略做判断，对墨水屏无感知。
- 你在 Kindle 浏览器里写
@media (update: slow) { ... }，整段规则会被直接忽略 - Android 平板开启省电模式时可能触发
update: slow，但这和墨水屏无关，且行为不稳定 - 没有浏览器会因为检测到 200ms 全局刷新延迟就自动设
update: slow—— 它不读取硬件帧率传感器
真正能识别墨水屏的替代方案
目前没有标准 CSS 方法直接识别墨水屏，但可通过组合特征+运行时探测逼近目标：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用
@media (pointer: coarse) and (hover: none) and (max-width: 1024px)筛出典型墨水屏使用场景（小屏、无悬停、触控粗粒度） - 配合 JS 检测
navigator.platform或userAgent中的关键词（如"Kindle"、"remarkable"），但注意 UA 可伪造 - 监听
matchMedia("(display-mode: standalone)").matches+screen.height 提高命中率（多数墨水屏分辨率集中在 1080×1440 或更低） - 关键：所有样式降级必须有 fallback——把墨水屏专用规则写在普通
@media screen下方，确保不匹配时仍可用
墨水屏适配的核心动作不是“关动画”，而是“控刷新”
电子墨水屏卡顿主因不是动画慢，而是全屏重绘触发全局刷新（慢至 300–800ms）。CSS 动画本身可能被强制转为“闪屏式”刷新，反而更伤眼。
立即学习“前端免费学习笔记（深入）”；
- 禁用所有
transition和animation，尤其是涉及opacity、transform的——它们在墨水屏上常触发意外全刷 - 用
will-change: unset覆盖默认合成层提示，避免浏览器误判为需高频更新 - 文本类操作优先用 class 切换（如
.highlight→.highlight-active），而非 JS 直接改style.opacity - 若必须动效，只用
visibility: hidden/visible切换，这是墨水屏最稳妥的显隐方式
墨水屏适配最难的点不在 CSS 写法，而在验证闭环：你没法靠 Chrome DevTools 模拟出真实刷新延迟，必须真机测试；而真机又缺乏开发者工具，所以得把日志打到页面角落或通过 USB 网络回传。别信“写了 update: slow 就万事大吉”这种说法——它连墨水屏的边都没摸到。
