placeholder中文显示方块或问号是因html文件编码（如gbk）与meta charset="utf-8"冲突，需保存为utf-8无bom并确保meta标签位于head开头无前置字符；动态赋值时js及模板文件也须utf-8编码。
placeholder 属性值中文显示为方块或问号
这说明浏览器读取到的 placeholder 字符串本身已是损坏状态，不是渲染问题，而是源头编码已错。常见于 HTML 文件保存时用了 GBK/ANSI 编码，但 <meta charset="UTF-8"> 又强制告诉浏览器按 UTF-8 解析——两者对不上，中文就塌陷成 或 □。
实操建议：
- 用 VS Code 打开该 HTML 文件，右下角查看当前编码（如显示
GBK或ISO-8859-1），不要点 “Reopen with Encoding”，直接点 “Save with Encoding” → 选UTF-8（注意：**不带 BOM**） - 确认
<meta charset="UTF-8">真实存在于开头、且前面**没有任何字符**（包括空格、BOM、注释） - 如果 placeholder 值来自 JS 动态赋值（如
input.placeholder = "搜索..."），检查 JS 文件本身是否也存为 UTF-8；若 JS 是后端模板拼接（如 EJS 中），需确保模板引擎输出时未二次转义或编码错乱
placeholder 中文正常但输入框聚焦后文字变乱
这是典型的“输入法 + 渲染层”叠加干扰。Chrome / Edge 在某些 Windows 版本上，当系统区域设为中文但字体缺失时，会 fallback 到不支持中文的等宽字体（如 Courier New），导致 placeholder 正常（因 CSS 未生效），而 focus 后触发 input 默认样式重绘，字体切换失败。
实操建议：
- 给 input 显式声明中文字体：
input { font-family: "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", sans-serif; } - 避免在 placeholder 上用
font-family单独设置（兼容性差），统一控制 input 元素字体即可 - 若项目用 Webpack/Vite 构建，检查 CSS 提取插件是否误删了字体声明（尤其
@font-face引入的自定义字体）
服务端渲染模板中 placeholder 中文被转义成 \uXXXX
常见于 Node.js 的 EJS、Nunjucks 或 PHP 的 Twig 模板中，后端把字符串 JSON.stringify() 过再塞进 placeholder，结果 "搜索" 变成 "\u641c\u7d22"，浏览器原样渲染这些 Unicode 转义序列，而非还原成汉字。
实操建议：
- EJS 中不要写：
<input placeholder="<%= JSON.stringify(tip) %>">；应写：<input placeholder="<%= tip %>"> - PHP Twig 中禁用 autoescape：用
{{ tip|raw }}替代{{ tip }}（前提是 tip 内容可信） - 若必须 JSON 输出（如初始化 JS 变量），应在 JS 层解析：
JSON.parse('"\u641c\u7d22"')，而非直接塞进 HTML 属性
移动端 Safari placeholder 中文偏移或截断
iOS 16+ Safari 对 placeholder 的行高和垂直对齐处理较特殊，尤其当 input 设置了 line-height、padding 或 height 时，中文 placeholder 容易被裁掉下半部分或整体上浮，看起来像“缺字”或“乱码”。
实操建议：
- 优先用
padding控制高度，避免同时设height和line-height - 加一行修复 CSS：
input::-webkit-input-placeholder { line-height: normal; } - 测试真机而非模拟器——iOS 模拟器的字体渲染与真机存在差异，常误报“乱码”
font 或 direction，但会受 input 元素的 unicode-bidi 和 text-align 影响。一旦页面有 RTL 布局或全局重置样式，placeholder 就可能悄悄变形。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
