UnicodeString::snake() 仅识别大小写字母边界，故“APIKey”变为“a_p_i_key”而非“api_key”；实操需先用replace()预处理缩写或数字，再调用snake()。
为什么 UnicodeString::snake() 不能直接处理带数字或特殊分隔的字符串
它只识别大小写字母边界，遇到 "APIKey" 会变成 "a_p_i_key"，而不是预期的 "api_key"；"XMLParser" 同样崩成 "x_m_l_parser"。这不是 bug，是设计使然——snake() 专注 Unicode 字母连写场景，不内置缩写词或数字感知逻辑。
实操建议：
- 先用
UnicodeString::replace()预处理常见缩写：比如把"API"替换成"Api"，再调snake() - 对含数字的串（如
"user123Name"），需手动插入分隔符：->replace('/(?replace('/(? - 注意顺序：数字相关替换必须在
snake()之前做，否则大小写规则已生效，数字边界就失效了
如何让 snake() 支持自定义分隔符（比如中划线）
snake() 内部硬编码了下划线，没提供参数接口。强行改分隔符得绕开它，用正则 + UnicodeString::replace() 模拟逻辑：
$s = new UnicodeString('camelCase');
$result = $s->replace('/(?<=[a-z])(?=[A-Z])|(?<=[A-Z])(?=[A-Z][a-z])/', '-')
->lower(); // → "camel-case"
关键点：
- 正则里两个断言缺一不可：
(? 处理小→大，<code>(? 处理大→大+小（如 <code>"XMLHttp"中的"MHttp"） - 必须最后调
lower()，否则"CamelCase"会变成"Camel-Case" - 别用
trim()或额外replace('_-', '-')—— 这个正则本身不会产生多余分隔符
从下划线转驼峰时，UnicodeString::camel() 和 title() 的区别在哪
camel() 输出首字母小写（"user_name" → "userName"），title() 是首字母大写（"user_name" → "UserName"）。但两者都默认按 "_" 分割，不支持其他分隔符（如 "-" 或空格）。
如果源字符串是 "user-name"，直接调 camel() 会失败（返回原串），因为没识别中划线。正确做法：
- 先统一替换分隔符：
->replace('-', '_')->camel() - 若存在混合分隔符（
"user_name-and-id"），用replace('/[-\s]+/', '_')归一化 - 注意
camel()对连续下划线（"user__name"）会生成"user_name"（保留双下划线），不是去重，这点和 Laravel 的Str::camel()不同
性能敏感场景下，是否该避免使用 Symfony String 组件
单次调用开销微乎其微，但高频循环中（比如解析上万行 CSV 字段名），UnicodeString 构造对象 + 方法链式调用比原生 str_replace() + preg_replace() 慢约 15–20%。不过，差异主要来自对象创建和方法分发，不是正则本身。
优化建议：
- 批量处理时，把转换逻辑提到循环外，复用正则 pattern（PHP 7.4+ 可用
static $pattern缓存） - 纯 ASCII 场景（无 Unicode），用原生函数更稳：
lcfirst(ucwords(str_replace('_', ' ', $str)))虽不完美，但快且无依赖 - 真正瓶颈往往不在这里——先 profile 确认是不是这行代码拖慢，别过早优化
复杂点在于缩写词和数字边界的组合判断，没有银弹方案；多数项目用预处理 + snake() 就够用，真要极致控制，就得自己写状态机式的分割器。
