根本原因是Chrome与Safari渲染引擎对caret-color标准支持节奏不同：Chrome 57+、Firefox 53+原生支持，Safari 11.1+才开始支持且≤14.1仅认-webkit-caret-color；新版Chrome/Firefox忽略后者但无副作用，故必须同时声明两个属性且caret-color在前、-webkit-caret-color在后。
为什么Chrome和Safari的caret-color表现不一致
根本原因不是写法错，而是两套渲染引擎对标准的支持节奏不同：Chrome 57+ 和 Firefox 53+ 原生支持 caret-color，但 Safari 直到 11.1+ 才开始支持，且 ≤14.1 版本**只认 -webkit-caret-color**；而新版 Chrome/Firefox 会忽略后者，但加了也无副作用。这意味着单写 caret-color 在老 Safari 里完全失效，单写 -webkit-caret-color 在新 Chrome 里虽不报错，但可能被后续规则覆盖或未命中预期节点。
必须同时声明两个属性，且顺序不能颠倒
最简可靠的写法是显式并列声明，不依赖 @supports 或 JS 检测：
input, textarea {
caret-color: #007bff;
-webkit-caret-color: #007bff;
}
-
caret-color放前面：确保现代浏览器优先走标准路径 -
-webkit-caret-color紧跟其后：兜底 Safari ≤14.1（包括部分 iOS 15.3 及更早设备） - 不要用
@apply或动态拼接类名：Tailwind JIT 不解析theme()函数，class="caret-blue-500"在 Tailwind 4.0 中默认不生效 - 避免写在父级选择器里（如
.form-group input）：容易被更高权重规则覆盖，直接作用于input或textarea更稳
移动端和密码框的特殊限制必须绕开
Safari 15–16.3 对 input[type="password"] 有已知渲染 bug：光标颜色仅聚焦瞬间闪现，随后退回黑色。这不是 CSS 写法问题，而是 WebKit 渲染层缺陷，2026 年 6 月仍未修复。实操中应：
- 对密码框单独跳过自定义：
input:not([type="password"]) { caret-color: #ff6b6b; -webkit-caret-color: #ff6b6b; } - 表格内
input失效？检查是否被table的font-size缩放影响——iOS Safari 会按渲染后字号重算光标，建议用固定px值或rem配合根字体控制 - 深色模式下别指望
dark:caret-indigo-400自动切换：caret-color 不响应prefers-color-schemeclass 切换，需手动加媒体查询
验证是否真正生效的三步法
别只看页面效果，很多“没变色”其实是样式没落到位：
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Elements → 选中目标
input→ 切到 Computed 标签页，搜索caret-color，确认最终值是你设的色值（不是auto或initial） - 临时把颜色设成高对比色（如
#ff00ff），排除因背景/文字色相近导致的视觉误判 - 真机测试软键盘弹出后状态：iOS Safari 在键盘激活时可能强制重置光标为系统色，模拟器无法复现
真正难处理的从来不是怎么写，而是哪些场景根本不能写——比如 contenteditable 区域、input[type="number"]、被 pointer-events: none 阻断的容器，这些地方 caret-color 从底层就被禁用，强行加只会浪费调试时间。
