caret-color 仅对具有文本插入点的可编辑元素生效，如 text、search、url、tel 类型 input、textarea 和显式设置 contenteditable="true" 的 div；在 number、checkbox 等无插入点元素及普通 div/span 上无效。
caret-color 能直接改光标颜色，但写了不生效是常态——不是浏览器不支持，而是它只在特定元素、特定状态、特定样式优先级下才起作用。
哪些元素上 caret-color 真的生效
只对有真实文本插入点（text insertion point）的可编辑元素有效：
-
input[type="text"]、input[type="search"]、input[type="url"]、input[type="tel"] textarea-
div[contenteditable="true"]（注意：必须显式带该属性，且焦点落在这个 div 上）
以下完全无效：
-
input[type="number"]、input[type="checkbox"]、input[type="radio"]—— 它们压根不用插入点机制 - 没加
contenteditable="true"的普通div或span - 富文本编辑器里外层容器设了
caret-color，但实际编辑区是内嵌的textarea或另一个contenteditable元素
写了 caret-color 却没变色的常见原因
绝大多数问题出在样式没落到目标节点，或被覆盖/重置：
立即学习“前端免费学习笔记（深入）”；
- 某处全局写了
input { caret-color: auto !important; }，比如 UI 框架或 Normalize.css - 父级设置了
color: transparent，子元素又没显式声明caret-color，导致光标继承为透明（看不见 ≠ 没生效） - iOS Safari 对
font-size渲染值敏感，若计算后小于 16px，caret-color可能被忽略 - Chrome 115+ 启用了系统级“强制颜色滤镜”时，该属性会被浏览器静默禁用
- DevTools 里检查 computed 值，发现最终
caret-color是auto或initial，说明规则根本没命中
怎么写才大概率生效且兼容
别搞复杂检测，用最简但覆盖主力场景的写法：
- 统一加标准 + WebKit 前缀：
input, textarea { caret-color: #007bff; -webkit-caret-color: #007bff; } - 深色模式下别硬写死，配媒体查询：
@media (prefers-color-scheme: dark) { input { caret-color: #4ecdc4; } } - 避开已知 bug 场景：Safari 15–16 对
input[type="password"]的caret-color渲染异常，建议单独跳过或降级 - 别依赖
currentColor——caret-color不响应父级color变化，必须写死值或用 CSS 变量（如--cursor-color）并显式赋值
和 color、:focus 配合的注意事项
caret-color 和 color 独立工作，但容易误判：
- 想只改光标色不改文字色？必须同时写：
input { color: #333; caret-color: red; } - 别只靠
:focus控制caret-color—— 光标在聚焦状态下才可见，但属性本身不需要伪类触发；加:focus只是为了避免其他样式干扰（比如某些框架会重置 focus outline 导致双光标） - macOS Safari 有时会强制调整浅色光标对比度（比如你设
#ffffff，实际渲染成灰白），这不是 bug，是系统级可访问性干预，无法绕过
真正难的不是写那行 caret-color，而是确认它落在了对的节点、没被更高优先级规则干掉、且浏览器没在后台悄悄覆盖它。调试时先设成 red 或 #ff00ff，再直奔 DevTools 的 Computed 面板看最终值——比猜强得多。
