必须用 mb_strlen() 而非 strlen() 校验中文字符串长度，因 strlen() 按字节计算导致“你好”返回6，而用户感知为2个字符；需显式指定 ‘UTF-8’ 编码、启用 mbstring 扩展，并配合前端 JS 的 Array.from().length 及后端清洗（trim、去零宽字符）确保准确。
用 strlen() 还是 mb_strlen()？中文输入必须分清
PHP 判断用户输入字符串长度，最常踩的坑就是用 strlen() 量中文——它按字节算，一个 UTF-8 中文占 3 字节，strlen("你好") 返回 6，但用户眼里是 2 个字符。表单校验要的是“用户感知的长度”，不是字节长度。
正确做法：统一用 mb_strlen($str, 'UTF-8')，并确保 PHP 已启用 mbstring 扩展（绝大多数现代环境默认开启）。如果不确定，先检查：extension_loaded('mbstring')。
- 表单接收后立即用
mb_strlen($_POST['username'], 'UTF-8')校验 - 若前端传了非 UTF-8 编码（极少见），需先
mb_convert_encoding()转换，否则结果不可靠 -
mb_strlen()第二个参数不写可能 fallback 到mb_internal_encoding()，建议显式传'UTF-8'
表单提交前 JS 校验和 PHP 后端校验必须都做
前端用 JavaScript 的 input.length 或 new Blob([input]).size 都不准——JS 的 String.prototype.length 对 UTF-16 代理对处理不一致，比如 emoji ?（U+1F30D）在 JS 中算 2，但用户只当 1 个字符。所以 JS 层建议用 Array.from(input).length 或 input.codePointAt() 循环计数，更稳妥。
但无论 JS 多准，PHP 后端校验绝不能省。用户可禁用 JS、绕过前端、用 curl 直接 POST 脏数据。
立即学习“PHP免费学习笔记（深入）”；
- JS 示例（兼容 emoji）：
Array.from(document.getElementById('title').value).length > 20 - PHP 示例：
if (mb_strlen($_POST['title'] ?? '', 'UTF-8') > 20) { die('标题不能超过20个字符'); } - 注意空值：用
$_POST['field'] ?? ''避免未定义索引警告
max_length 和 maxlength 不是一回事，别指望 HTML 属性保平安
是浏览器原生限制，仅防误操作，完全可被绕过（删掉属性、改 DOM、用 Postman 提交）。而数据库字段的 max_length（如 MySQL 的 VARCHAR(50)）是存储层约束，触发时抛出 SQL 错误，不是友好的用户提示。
真正可控、可定制提示、可统一处理的，只有 PHP 层的逻辑校验。把它当成唯一可信防线。
- HTML 的
maxlength可以留着提升体验，但绝不依赖 - 数据库字段长度应 ≥ PHP 校验上限（例如 PHP 限制 30，DB 设
VARCHAR(32)），留点余量防编码转换或 BOM 等意外 - 若用 Laravel / Symfony 等框架，优先走
Validation规则（如'title' => 'required|string|max:20'），底层仍是mb_strlen
特殊字符、空格、不可见符容易让长度“偷偷超标”
用户复制粘贴时可能带全角空格、零宽空格（/u200B）、BOM、换行符等。这些字符 mb_strlen() 全部计入，但肉眼难察觉，导致“明明没输满却提示超长”。
建议在 PHP 校验前做轻量清洗：
- 用
trim()去首尾空白（含全角空格、/r/n/t 等） - 用
preg_replace('/[/x{200B}-/x{200D}/x{FEFF}]/u', '', $str)清零宽字符（正则需/u修饰符） - 若业务允许，可额外加
mb_ereg_replace('^/s+|/s+$', '', $str)更彻底去空格 - 清洗后再用
mb_strlen()校验，避免用户困惑
字符边界永远比看起来复杂——emoji、中日韩标点、组合字符（如带声调的拉丁字母）、双向文本控制符……只要涉及用户自由输入，就得默认它们存在。校验逻辑里多一行清洗，比上线后收一堆“为什么我只打了5个字就报错”的工单划算得多。