caret-color仅对可编辑文本元素生效：input[type="text/search/url/tel"]、textarea及contenteditable="true"的元素；对number/checkbox/radio等无效，且不继承、需显式设置并确保焦点状态与浏览器支持。
caret-color 能直接改光标颜色，但只在特定条件下生效——不是所有 input 都认它，也不是写了就一定变。
哪些元素上 caret-color 真的起作用
只对真正能输入文本、有插入点（text insertion point）的元素有效：input[type="text"]、input[type="search"]、input[type="url"]、input[type="tel"]、textarea，以及 div[contenteditable="true"]。
以下情况完全无效：
-
input[type="number"]、input[type="checkbox"]、input[type="radio"]—— 它们不走文本插入模式 -
div没加contenteditable="true"属性 - 富文本编辑器里套了多层 wrapper，你给外层设了
caret-color，但真实编辑区域是内层div[contenteditable]或textarea
调试建议：用 DevTools 点击元素，看焦点是否落在你设样式的那个节点上；如果不是，就去定位真实编辑容器。
为什么写了 caret-color 却没变化
最常见原因不是属性不支持，而是样式没落到目标节点或被覆盖：
立即学习“前端免费学习笔记（深入）”；
- 被更高优先级规则重置，比如某处写了
input { caret-color: auto !important; }，或 UI 框架（如 Normalize.css）全局设了caret-color: auto - 父级设置了
color: transparent，子元素又没显式声明caret-color，导致光标继承为透明（看不见 ≠ 未生效） - 移动端 iOS Safari 在
font-size渲染值 caret-color，哪怕你写的是1rem - Chrome 115+ 启用了系统级“强制颜色滤镜”时，
caret-color可能被浏览器直接忽略
验证是否生效：临时把值设成 red 或 #ff00ff，再检查 Computed 面板里 caret-color 的最终值是不是你预期的。
怎么写才安全兼容
不用 JS 检测，也不必层层 @supports 套嵌，简洁直接更可靠：
- 统一加标准写法 +
-webkit-caret-color前缀：input, textarea { caret-color: #007bff; -webkit-caret-color: #007bff; } -
-webkit-caret-color在新版 Chrome/Firefox 中会被忽略，无副作用；Safari ≤14.1 必须靠它 - 深色模式下别硬写死颜色，配合媒体查询：
@media (prefers-color-scheme: dark) { input { caret-color: #4ecdc4; } } - 密码框在 Safari 15–16 有渲染 bug（2026 年 6 月仍存在），若需支持，建议对
input[type="password"]单独降级处理或跳过自定义
和 color、focus 怎么配合用
caret-color 和 color 不冲突，但有明确优先级：显式设置 caret-color 就会覆盖默认行为（即不再跟随 color）。
- 想让光标始终高对比：显式设
caret-color: #fff或caret-color: #000 - 想随文字变色但保持可见：用
caret-color: currentColor（注意旧浏览器不支持该值） - 结合伪类动态控制：
input { caret-color: #999; } input:focus { caret-color: #007bff; }，比监听事件改 style 更轻量 - 但注意：如果同时清除了
outline又没提供其他焦点反馈，会损害可访问性；光标颜色变化不能替代 focus outline
真正容易被忽略的是：当元素用了 appearance: none 或自定义 border/box-shadow 时，光标位置可能因盒模型计算偏差而看起来“偏移”——这不是 caret-color 的问题，而是整体样式布局需要微调。
