拼接大量字符串应避免 .= 而改用数组收集后 implode，截取中文必须用 mb_substr() 并显式指定 'UTF-8' 编码，混用 strpos() 与 mb_substr() 或编码不一致会导致乱码或错位。
拼接别用 .= 循环，截取中文别用 substr() —— 这两个操作踩坑最多，直接导致乱码或性能崩掉。
拼接大量字符串时为什么不能用 .=
每次 .= 都会触发内存重分配和内容复制，1000 次拼接可能产生 1000 次内存拷贝。PHP 的 zend_string 虽有引用计数，但 .= 是写时复制的典型触发点。
- 用
array收集片段，最后implode('', $parts)—— 内存只分配一次，速度提升 3–5 倍 - 双引号内插只适合少量变量，如
"Hello {$name}"；千万别写"{$a}{$b}{$c}..."堆叠几十个 - 单引号字符串不解析变量，
'static text'比"static text"少一次解析开销 - 生成 HTML 片段时，优先考虑
heredoc（支持变量插值且可读性好），避免多层嵌套点号
截取中文必须用 mb_substr() 而不是 substr()
substr() 按字节切，UTF-8 下一个中文占 3 字节，substr("你好", 0, 2) 极大概率输出乱码（比如 "你" 的前 2 字节）。mb_substr() 才按“字符”数切，安全可靠。
- 必须显式传编码：
mb_substr($str, 0, 10, 'UTF-8')，不能依赖默认值，尤其在 CLI 环境下内部编码可能不是 UTF-8 - 检查扩展是否启用：
extension_loaded('mbstring')，没启用会 fatal error - 如果只是截取英文/数字路径、URL 参数等纯 ASCII 场景，
substr()更快，不用强切mb_* -
mb_strcut()是字节级截取（保证编码完整），适用于 API 响应体长度硬限制（如 ≤2048 字节），和mb_substr()的“字符数”逻辑完全不同
动态位置截取优先用 strpos() + mb_substr() 组合
想从 “user@example.com” 截出 “example”，靠猜偏移量不现实。得先定位 @ 和 .，再算起始和长度。
- 别用
explode('@', $email)[1]再explode('.', ...)[0]—— 多次分割开销大，且无法处理带多个 @ 的非法输入 - 正确姿势：
$posAt = mb_strpos($email, '@');+$posDot = mb_strpos($email, '.', $posAt);+mb_substr($email, $posAt + 1, $posDot - $posAt - 1, 'UTF-8') -
mb_strpos()必须配mb_substr()，混用strpos()和mb_substr()会导致偏移错位（字节 vs 字符） - 注意返回
false的情况，mb_strpos()找不到时返回false，直接参与计算会变成 0，必须判空
最易被忽略的是编码一致性：所有 mb_* 函数必须用相同 $encoding 参数，且与源字符串真实编码一致。传错 'GBK' 处理 UTF-8 字符串，结果不可预测，调试时很难复现。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
