WordPress REST API 的 pattern 参数要求提供不带分隔符的原生正则表达式，若误加 / 等定界符会导致匹配失败；核心原因是内部函数自动添加 # 作为分隔符并启用 Unicode 模式（#u），双重定界引发语法错误。
wordpress rest api 的 `pattern` 参数要求提供不带分隔符的原生正则表达式，若误加 `/` 等定界符会导致匹配失败；核心原因是内部函数自动添加 `#` 作为分隔符并启用 unicode 模式（`#u`），双重定界引发语法错误。
在 WordPress REST API 中为请求参数配置正则校验时，开发者常因沿用 PHP 原生 preg_match() 的书写习惯，在 pattern 字段中错误地包含正则分隔符（如 /^[A-Za-z0-9 ]+$/），从而导致验证始终失败，并返回 rest_invalid_pattern 错误。
根本原因在于 WordPress 内部使用了 rest_validate_json_schema_pattern() 函数进行校验：
function rest_validate_json_schema_pattern( $pattern, $value ) {
$escaped_pattern = str_replace( '#', '\#', $pattern );
return 1 === preg_match( '#' . $escaped_pattern . '#u', $value );
}该函数会：
- 自动以 # 作为正则分隔符（而非 /）；
- 在模式前后添加 #，并追加 u 修饰符（支持 UTF-8 Unicode 字符）；
- 对 # 字符做转义，避免冲突。
因此，当你传入 ' /^[A-Za-z0-9 ]+$/ '，实际执行的是：
preg_match('#/^[A-Za-z0-9 ]+$/#u', $value)这构成非法正则语法（开头的 / 被当作字面量，而非分隔符），必然返回 false。
论文常用的tex格式转换为word格式，核心是能转换数学公式（非图片），表格，图表等等
下载
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
✅ 正确写法：省略所有分隔符，仅提供纯模式字符串
register_rest_route( $this->namespace, '/posts', [
'methods' => 'POST',
'permission_callback' => '__return_true',
'callback' => 'create_post',
'args' => [
'title' => [
'type' => 'string',
'description' => 'The post's title',
'required' => true,
'pattern' => '^[A-Za-z0-9 ]+$', // ✅ 无 /、# 等分隔符
],
],
]);? 验证示例（与 PHP 一致）：
// 正确匹配（等效于 WordPress 内部执行） var_dump( preg_match( '#^[A-Za-z0-9 ]+$#u', 'Test Title' ) ); // int(1) var_dump( preg_match( '#^[A-Za-z0-9 ]+$#u', '&Invalid!' ) ); // int(0)
⚠️ 注意事项：
- 不要使用 /、# 或其他符号包裹正则，否则将被重复解析；
- u 修饰符已默认启用，需确保模式兼容 UTF-8（例如中文字符需显式写入，如 [p{L}p{N} ]+）；
- 特殊字符如 # 若需匹配，必须手动转义：pattern => 'My#Title'；
- 空字符串 '' 默认通过（除非配合 minLength 限制）；
- 建议配合 sanitize_callback 进行二次清理，增强健壮性。
总结：WordPress REST API 的 pattern 是 JSON Schema 规范的实现，遵循 JSON Schema Validation 标准——它只接受 ECMAScript 风格的正则字符串（无分隔符、无修饰符），由底层适配为 PCRE 兼容格式。理解这一设计边界，是写出可靠 API 参数校验的关键。
