先记住这个答案
accept-charset 影响表单数据编码，不能代替页面自身的字符集声明，也不能指挥服务端如何解码。现代页面通常让 HTML、表单提交和服务端都使用 UTF-8；如果其中一环误按旧编码读取，中文仍会乱码。排查时应先确认请求体和响应头的真实字节与编码，不要只改表单属性。
accept-charset作用于提交编码- 现代页面宜统一 UTF-8
- 服务端也要按同一编码解析
- 它不修复页面显示乱码
中文姓名提交后出现乱码
一个旧页面使用非 UTF-8 文档编码，中文姓名提交后服务端显示乱码。只在表单上加 accept-charset="UTF-8" 可能帮助提交编码一致，但还要确认页面的 <meta charset>、响应头以及服务端解析配置。对于 application/x-www-form-urlencoded，非 ASCII 字符会先按选定字符编码转成字节，再参与表单编码；服务端若以另一种字符集解码，仍然乱码。
<meta charset="UTF-8">
<form action="/profile" method="post" accept-charset="UTF-8">
<label>姓名
<input name="name" autocomplete="name">
</label>
<button type="submit">保存</button>
</form>页面编码与表单提交编码是两个相关但不同的阶段。
示例使用普通 application/x-www-form-urlencoded 表单提交时，中文姓名会先按提交编码转成字节，再经过表单编码传输。服务端若把这些字节误按另一编码解码，即使页面 <meta charset="UTF-8"> 和 accept-charset="UTF-8" 都正确，最终仍可能存成乱码。排查要抓一次真实请求并追踪服务端解码路径，不能靠前端“看着显示正常”判断链路没问题。
页面编码与提交编码分开
accept-charset 影响提交数据的字符编码选择；浏览器向服务器发送的字节还受表单的 enctype 和提交方式影响。现代项目统一 UTF-8 时通常不需要在每张表单重复声明，但服务端仍必须按相应编码解析。乱码排查要看浏览器实际发出的请求、请求头与服务端解析，而不是只看输入框里的文字是否正常。
同一份中文姓名在浏览器里显示正常，提交后后台变乱码，不一定是输入框的问题。先在 Network 面板看请求体按什么编码发出，再确认服务器按同一种编码解码，以及响应数据库连接是否也使用 UTF-8。accept-charset 只覆盖表单提交这一环；页面 <meta charset> 管文档解码，接口请求头和服务端处理还各有自己的配置。
容易答错的地方
- 以为
accept-charset会修复页面文字乱码 - 页面文字显示由文档编码和资源解码决定，表单属性只涉及提交阶段。
- 只改浏览器端就认为后端会正常解码
- 服务端也需按相同编码处理表单字节，否则提交仍可能乱码。
面试官还会怎么问？
不写时默认用什么？
通常使用文档字符编码；现代页面以 UTF-8 为主，最好让前后端编码保持一致。
它与 enctype 有什么区别？
前者决定字符如何编码成字节，后者决定表单数据怎样封装提交。
为什么输入时正常，提交后乱码？
显示阶段和提交、服务端解码阶段不同，检查请求字节及服务端采用的字符集。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。