accent-color仅对移动端input[type="checkbox"]、input[type="radio"]、input[type="range"]（已填充轨道）和progress四类控件的强调区生效，需保留原生渲染、禁用appearance:none、避免transparent/currentcolor值，并直接作用于控件自身。
accent-color 在移动端能用，但别指望它“一键适配全部”——它只对 input[type="checkbox"]、input[type="radio"]、input[type="range"]（仅已填充轨道）、progress 四类控件生效，且必须保留原生渲染路径。
哪些移动端控件真正响应 accent-color？
iOS Safari 15.4+ 和 Android Chrome 93+ 已稳定支持，但仅限以下四类原生控件的「强调区」：
-
input[type="checkbox"]：勾选标记（✓）和选中背景色 -
input[type="radio"]：内部圆点填充色 -
input[type="range"]：已填充轨道部分（不包括::thumb） -
progress：已完成进度条部分（不包括 未完成轨道）
以下写了也白写：select、textarea、input[type="text"]、input[type="date"]、button。它们的颜色得靠 border、background、color 单独控制。
为什么在 iOS 或安卓 WebView 里 accent-color 没反应？
最常见原因不是兼容性问题，而是破坏了生效前提：
- 加了
appearance: none或-webkit-appearance: none→ 原生结构被剥离，accent-color失去作用对象 - 值用了
transparent或currentcolor→ Chrome 直接忽略，Firefox 控制台报 warning - 在父容器（如
form或label）上设accent-color→ 它不继承，必须直接写在控件自身上 - 没配
<meta name="color-scheme" content="light dark">→ Safari/Chrome 在深色模式下可能降级用系统色，导致颜色不一致
如何安全高效地批量设置移动端主题色？
推荐两种写法，兼顾可维护性和可控性：
- 全局统一（最省事）：
:root { --theme-accent: #3b82f6; accent-color: var(--theme-accent, #007bff); }利用继承性，所有子树中支持的控件自动染色；注意变量 fallback 要写全，避免未定义时退成auto - 精准匹配（更可控）：
input[type="checkbox"], input[type="radio"], input[type="range"], progress { accent-color: var(--theme-accent); }显式限定范围，不依赖继承，也不怕父级样式干扰
别漏掉关键补位：移动端 input[type="range"] 的滑块把手（::thumb）仍需单独设 background-color；progress 的未完成轨道得用 background 或伪元素覆盖；checkbox 在 indeterminate = true 状态下颜色强制为灰色，accent-color 完全无效——这是规范限制，不是 bug。
真正容易被忽略的是：一旦你为了“更好看”加了 appearance: none 或用伪元素重绘控件，accent-color 就彻底退出游戏——这时候就得切回传统手绘方案，和它无关了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
