sublime text 正则替换是typescript类型重构中最可控的批量修改手段；它不依赖tsserver语义分析，通过\b、^、(?=)等模式精准匹配interface/type声明及注解，避开字符串、注释和泛型参数误改，但需人工验证残留与编译错误。
Sublime Text 的正则替换不是“辅助功能”，而是 TypeScript 类型重构中最快、最可控的批量修改手段——尤其当你面对 interface 重命名、type 拆分、泛型参数清理等不涉及语义分析的机械性变更时，它比 LSP 跳转+多光标更稳，比手动改更准。
为什么不用 LSP 或 TS 语言服务来重命名类型
TS 语言服务（tsserver）的 rename 请求只作用于“可解析的标识符引用”，但以下情况它直接失效：
- 类型名出现在字符串里（如
console.log("UserType")）或注释中，tsserver 不触碰 - 类型别名被动态拼接（如
const key = `${prefix}Request`），静态分析无法推导 - 项目未正确加载
tsconfig.json（常见于 Sublime 中 tsserver_path 配置错误或include路径遗漏），此时 rename 返回空结果却无提示 - 跨文件引用未保存时，tsserver 缓存未更新，rename 只改了当前缓冲区
而正则替换是纯文本操作，只要模式写对，所有匹配项一视同仁，不依赖上下文是否“有效”。
安全替换 TypeScript 类型名的关键正则模式
直接搜 User 然后替换成 Account？会误伤 username、userList、superuser。必须用单词边界 + 上下文锚点：
- 匹配顶层
interface User {：用^interface\s+User\b(?=\s*\{)，^锁定行首，\b防止子串匹配，(?=\s*\{)确保后面紧跟着{ - 匹配
type User =声明：用^type\s+User\b(?=\s*=)，同理限定右侧为= - 匹配类型注解中的
User（非泛型参数）：用(?)，排除<user></user>中的User；若要包含泛型内，改用\bUser(?= - 全局替换后检查残留：搜
\bUser\b并人工确认每处，尤其注意import { User } from和export type { User }行
替换泛型参数和工具类型时的陷阱
泛型参数名（如 TUser）、工具类型参数（如 Pick<user></user>）容易被粗暴替换破坏结构。例如把 User 全局替成 Account，会导致 Pick<account></account> —— 这看似正确，但若原意是保留 User 类型、仅改其字段，则已越界。
- 先隔离泛型上下文：用
]*User[^>]*>匹配整个泛型调用，再决定是否替换内部User - 区分声明与使用：声明处（
interface User、type User =）必须改；使用处（const u: User、function f(u: User)）通常也该改，但Pick<user k></user>中的User是类型参数，应与声明同步，而非单独处理 - 避免误吞泛型尖括号：不要用
.*User.*，它会跨行吞掉中间内容；用[^}]*User[^}]*限制在单行内，或启用 Sublime 的. matches newline选项并加^/$控制范围
替换后必须验证的三件事
正则改完不等于结束，TypeScript 编译器才是最终裁判：
- 运行
tsc --noEmit --skipLibCheck看是否报新错；特别关注Cannot find name 'XXX'（漏替换）或Type 'YYY' is not assignable to type 'ZZZ'（多替换） - 打开 Sublime 的 TypeScript 插件错误面板（或 LSP diagnostics），确认没有因类型名不一致导致的红色波浪线
- 检查
tsconfig.json中的include是否覆盖所有被修改文件；如果某.ts文件不在include列表里，tsserver 根本不校验它，正则改了也白改
最易被忽略的是：正则能精准定位类型名，但无法判断该类型是否被其他模块通过路径别名（如 @/types/User）引用——这类引用需同步更新 paths 映射或文件路径，否则编译时仍报错。
