caret-color仅对具有文本插入点的元素生效：input[type="text/search/url/tel"]、textarea及contenteditable="true"的元素；对number/checkbox/radio等无效，且不继承、需显式设置并确保焦点状态与浏览器支持。
哪些元素上 caret-color 真的生效
只对有文本插入点（text insertion point）的元素起作用：input[type="text"]、input[type="search"]、input[type="url"]、input[type="tel"]、textarea，以及显式声明 contenteditable="true" 的元素（如 div[contenteditable="true"]）。
以下情况完全无效：
• input[type="number"]、input[type="checkbox"]、input[type="radio"] —— 它们不走文本输入逻辑
• 没加 contenteditable="true" 的普通 div 或 td
• 富文本编辑器里你设样式的外层 wrapper，但真实编辑区域是内层 textarea 或可编辑 div
调试时用 DevTools 点击元素，确认焦点是否落在你写了 caret-color 的那个节点上。
为什么写了 caret-color 却没变色
不是浏览器不支持，而是样式没落到目标节点或被覆盖：
• 被更高优先级规则重置，比如全局 CSS 里写了 input { caret-color: auto !important; }
• 父级设置了 color: transparent，子元素又没显式声明 caret-color，导致光标继承为透明（看不见 ≠ 未生效）
• iOS Safari 对 font-size 渲染异常时会连带忽略 caret-color（哪怕你写的是 1rem）
• Chrome 115+ 启用系统级“强制颜色滤镜”时，caret-color 可能被直接静默丢弃
验证是否生效：临时把值设成 red 或 #ff00ff，再看 DevTools 的 Computed 面板里 caret-color 的最终计算值。
移动端光标“闪退”或复位到灰色怎么办
这不是代码问题，而是 Safari（iOS 16–17）和部分安卓 WebView 的渲染限制：软键盘弹出后，光标色可能短暂回退到系统默认色。
临时有效解法只有这一条：
• 在目标元素（必须是 input 或 textarea 本身）上加 transform: translateZ(0)
• 切记别加在父容器上——加了也没用
• 对 input[type="password"] 要格外小心：Safari 15–16.3 存在已知渲染 bug，表现为光标变浅灰、偶发卡顿；建议对该类型直接跳过自定义，保持 caret-color: auto，或仅在加 transform: translateZ(0) 的同时配 -webkit-appearance: none（后者仅限非语义化表单场景）
深色模式下光标看不见或对比度不足
常见误区是以为“颜色没变”，其实是系统强制降级了明度（比如 caret-color: #fff 在黑背景上被 Safari 渲染成浅灰）。
真正有效的做法：
• 用 @media (prefers-color-scheme: dark) 单独设值，例如 caret-color: #4ecdc4
• 避免纯白 #ffffff 和纯黑 #000000，选中等明度色（如 #6a99ff、#ff6b6b）
• 别依赖 currentColor —— 它在深色模式下可能继承自不可控的父级 color 值
• 自动填充（input:-webkit-autofill）会彻底忽略 caret-color，这是 Chrome/Edge 的 UA 样式层行为，绕不过；业务允许时，用 autocomplete="new-password" 更可靠。
最常被忽略的一点：caret-color 不继承、不响应 currentColor 动态变化、在 macOS Safari 上还可能被系统强制调色 —— 所以它从来不是“设一次就完事”的属性，而是一个需要逐场景校验的视觉细节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
