本文详解为何 str_replace() 会导致重复添加 locale（如 /us/），并提供基于正则负向先行断言的精准替换方案，避免误匹配已含 locale 的 URL。
本文详解为何 `str_replace()` 会导致重复添加 locale（如 `/us/`），并提供基于正则负向先行断言的精准替换方案，避免误匹配已含 locale 的 url。
在 WordPress 多语言站点中，为内部链接动态注入 locale（如 en_US → /us/）是常见需求。但直接使用 str_replace() 替换原始 URL 存在严重隐患：它不区分上下文，会无差别匹配所有出现位置。例如，当 $arr['https://example.com'] = 'https://example.com/us' 时，str_replace() 会将 中的 https://example.com 也替换为 https://example.com/us，最终变成 https://example.com/us/us/about —— 明显错误。
根本原因在于 str_replace() 是纯字符串替换，不具备“仅匹配完整、未修饰的 URL”这一语义能力。解决方案是改用 preg_replace()，配合负向先行断言（negative lookahead） 精确限定替换条件：
// 提取所有 href 值
preg_match_all('/<a>]*?\s+)?href=([\'"])(.*?)\1/', $content, $matches);
$replacements = [];
$current_locale = get_current_locale();
if (!empty($matches[2])) {
foreach ($matches[2] as $url) {
// 跳过邮箱地址
if (preg_match('/\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b/i', $url)) {
continue;
}
$new_url = add_locale_to_url($url, $current_locale);
if ($new_url !== $url) {
// 关键：仅当 $url 后不紧跟 '/us/'（或对应 locale 路径）时才匹配
// 注意：需对 $url 进行 preg_quote() 防止特殊字符破坏正则
$escaped_url = preg_quote($url, '#');
$pattern = "#{$escaped_url}(?!/{$current_locale}/)#i";
$replacements[$pattern] = $new_url;
}
}
}
// 批量执行正则替换（注意：preg_replace 接受 pattern => replacement 数组）
if (!empty($replacements)) {
$content = preg_replace(array_keys($replacements), array_values($replacements), $content);
}</a>
⚠️ 关键注意事项：
- 必须转义 URL：使用 preg_quote($url, '#')，否则 URL 中的 .、/、? 等会被正则引擎解析为元字符，导致匹配失败或意外行为；
- locale 路径需动态适配：示例中硬编码 /us/ 不通用，应使用变量 "/{$current_locale}/" 并确保其格式与 add_locale_to_url() 输出一致（如是否带前导 /、是否标准化大小写）；
- 避免全局污染：preg_replace() 的 i 修饰符启用大小写不敏感匹配，适用于多数场景；若需严格区分大小写（如某些 API 路径），请移除 i；
- 性能考量：对大量 URL 使用多个独立正则效率较低，生产环境建议合并为单个 preg_replace_callback()，但逻辑复杂度上升，需权衡可维护性与性能。
总结：str_replace() 适合确定、无歧义的字面量替换；而涉及上下文感知（如“仅替换未带 locale 的 URL”）时，必须借助正则表达式的锚点、边界符或断言机制。本方案通过负向先行断言 (?!/locale/) 确保替换的安全性与准确性，是多语言 WordPress 主题开发中的稳健实践。
