$matches[0]始终是完整匹配字符串，后续索引才对应捕获组；误用$matches[1]会导致未定义错误或替换失败，尤其在无捕获组、嵌套或可选结构时更需依赖$matches[0]。
preg_replace_callback 里怎么拿到整个匹配字符串
直接用 $matches[0] 就行，它始终是完整匹配内容。很多人误以为要从 $matches[1] 开始取捕获组，结果漏掉最外层匹配。
常见错误现象：回调函数返回空或错乱字符串，其实是把 $matches[1] 当成了全量匹配，而实际正则可能没写捕获组，或者捕获组位置不对。
-
$matches是个数组，$matches[0]固定存完整匹配文本 - 后续索引（
$matches[1]、$matches[2]…）才对应括号内的捕获组，按左括号出现顺序编号 - 即使正则里没写任何括号（比如
/\d+/），$matches[0]依然有效且唯一 - 如果用了命名捕获（如
/(?P<year>\d{4})/</year>），除了数字索引，还能用$matches['year']
为什么不能只依赖 $matches[1]？
因为 $matches[1] 只在正则中存在第一个捕获组时才有值；没有捕获组时它是 undefined，PHP 会报 Notice: Undefined offset —— 这类错误在开发环境可能被忽略，上线后导致替换失败却无日志。
使用场景举例：想把所有连续数字替换成带括号的格式，不管它前后有没有其他字符：
立即学习“PHP免费学习笔记（深入）”；
$text = 'abc123def4567';
$result = preg_replace_callback('/\d+/', function($m) {
return '(' . $m[0] . ')'; // ✅ 正确：用 $m[0]
}, $text);
// 输出：abc(123)def(4567)
如果写成 $m[1]，就会出错或返回空字符串。
捕获组嵌套或可选时，$matches[0] 更可靠
当正则含可选部分（?）、重复组（+、*）或嵌套括号时，捕获组数量和顺序容易混乱，但 $matches[0] 始终稳定。
例如：/(a)?(b+)(c)?/ 匹配 "bb" 时，$matches[1] 是 null，$matches[2] 是 "bb"，$matches[3] 是 null —— 但 $matches[0] 一定是 "bb"。
- 性能上没差异，
$matches[0]是原生填充，不额外计算 - 兼容性没问题，PHP 4.0.5+ 所有支持
preg_replace_callback的版本都如此 - 别试图用
preg_last_error()或mb_ereg替代，那是绕远路
回调函数参数名写错也会丢掉 $matches[0]
常见低级错误：把回调函数参数写成 function($match) 却在内部用 $m[0]，或者参数名带空格、下划线不一致，导致变量未定义。
必须严格匹配传入参数名：
// ✅ 正确
preg_replace_callback('/\w+/', function($matches) {
return '[' . $matches[0] . ']';
}, $str);
// ❌ 错误：参数名是 $m，但声明为 $matches
preg_replace_callback('/\w+/', function($matches) {
return '[' . $m[0] . ']'; // Notice: Undefined variable: m
}, $str);
真正容易被忽略的是：这个数组索引规则对所有 PCRE 回调函数（包括 preg_replace_callback_array）都一样，不是某个函数特例 —— 但文档里藏得深，靠试错成本高。
