默认正则不跨行匹配，需启用dotall模式并用[ss]?替代.，限定泛型层级、区分命名/匿名返回、预览匹配可避免误替换。
替换函数名和参数列表时，为什么 funcs+(w+)s*(([^)]*)) 会漏掉多行声明？
Go 函数签名常跨多行，尤其带长参数或结构体字段时，func 后换行、参数另起一行很常见。默认 Sublime 正则不跨行匹配，^ 和 $ 只锚定单行首尾，. 也不匹配换行符。
实操建议：
- 开启「dotall」模式：在 Sublime 查找框右下角点
.*按钮（或按Alt+R），让.匹配换行符 - 用
s*替代硬换行：把正则写成funcs+(w+)s*(([sS]*?))s*(?:->|)\s*([sS]*?){，其中[sS]显式覆盖所有字符（含换行） - 避免贪婪过头：参数部分用
[sS]*?而非[sS]*，防止从第一个(匹配到文件末尾最后一个)
重构接收者类型时，(*?w+)s+(w+)s* 为什么总错匹配嵌套指针或泛型？
Go 接收者如 func (r *Repository) List() 或 func (c *Client[T]) Do()，简单正则容易把 *Client[T] 中的 T 当作独立标识符，或把 *map[string]int 这类非法但可能存在的字符串误捕获。
实操建议：
- 限定接收者范围：用
(s*(*?[a-zA-Z_]w*(?:[[^]]*])?)s+([a-zA-Z_]w*)s*)，其中[[^]]*]容忍一层泛型，但禁止嵌套[[]] - 排除关键字干扰：在替换前先确认当前作用域无
type声明冲突，Sublime 不支持上下文感知，纯靠正则易误伤type User struct{}后面的func (u User) Name() - 接收者变量名必须保留：别用
$1直接替换整个接收者块，应只改类型部分，例如将$1改为*NewRepo，而$2（变量名r）保持不变
替换返回值类型时，如何安全处理多返回值和命名返回？
Go 支持 func() (int, error) 和 func() (v int, err error) 两种形式，后者命名返回值可能被误当作文档注释或变量引用。
实操建议：
- 区分命名/匿名返回：用
(?:->s*)?(([^)]*))s*{匹配匿名返回；用(?:->s*)?(([^)]*?w+s+w+(?:,s*)*))s*{捕获含空格的命名对（需配合手动校验） - 优先改签名不改实现：命名返回值在函数体内是变量，正则替换返回类型时，不要动函数体内的
return v, err—— 它们通常无需同步改，编译器会自动适配新签名 - 警惕空白符差异：有些代码用
func() (a, b int)，有些用func() (a int, b int)，正则中用s+和s*组合比固定空格更鲁棒
执行替换前，为什么必须先用 Find All 预览全部匹配？
Go 函数签名语法灵活，正则稍有偏差就会跨函数匹配（比如把两个相邻函数中间的注释或空行吞进去），或漏掉 interface 方法声明、test 文件中的 func TestXxx 等非业务函数。
实操建议：
- 禁用「In Selection」：确保不是只在选区里替换，否则可能漏掉文件其他位置
- 检查每处匹配高亮：Sublime 会标出捕获组，重点看
$1（函数名）、$2（参数）、$3（返回值）是否准确分界，尤其注意括号嵌套和换行位置 - 对复杂项目，先在小范围文件测试：比如只开一个
service.go，确认正则无误后再批量应用到**/*.go
最麻烦的其实是泛型嵌套和 receiver 中的复合类型，它们会让正则迅速失控；真遇到 func (x *T[map[string][]byte]) M() 这种，不如手动改——正则不是银弹，能省 80% 力气就该停手。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
