Go ast.FilterDecl 为什么不会过滤函数参数名

ast.FilterDecl 明确排除了参数列表中的名称。它按声明过滤规则裁剪 AST，不是对所有 ast.Ident 调用回调的通用遍历器。因此，保留函数 Send 时，参数 secret 不会因为回调只接受 Send 就被删除。这属于接口能力边界，不能据此推断过滤器失效或 Go 版本发生回归。

官方文档：https://pkg.go.dev/go/ast#FilterDecl

最小例子：声明保留不代表参数经过筛选

package main

import (
    "fmt"
    "go/ast"
    "go/parser"
    "go/token"
)

func main() {
    // 用独立源码演示过滤范围，不修改项目文件。
    src := "package demo; func Send(secret string) {}"
    file, err := parser.ParseFile(token.NewFileSet(), "demo.go", src, 0)
    if err != nil {
        panic(err) // 演示程序遇到语法错误立即退出。
    }
    decl := file.Decls[0].(*ast.FuncDecl)
    kept := ast.FilterDecl(decl, func(name string) bool {
        return name == "Send" // 保留声明名；这不是逐个标识符的遍历器。
    })
    fmt.Println(kept, decl.Type.Params.List[0].Names[0].Name)
}

按接口契约，示例中的 kept 为 true，参数名称仍为 secret。这里给出的是代码含义说明，未展示实际执行输出。示例只有一个函数声明，因此使用具体类型断言；处理任意文件时应使用类型分支，不能假定第一条声明总是函数。

如果你原先把 FilterDecl 当成“所有名称都要通过白名单”的接口，真正需要调整的是调用方对它的预期。没有依据时，不需要为这个现象寻找某个版本的行为变更。

为什么同样是 Field，结果却不同

在 AST 中，结构体字段、接口方法和函数参数都可能涉及 Field 节点。共享节点类型并不意味着 FilterDecl 会对它们执行相同的业务规则。理解过滤行为要看节点所在的位置，而不是只看节点的 Go 类型。

标准库文档将结构体字段名、接口方法名列入声明过滤范围，同时说明参数列表的名称不在其中。函数声明的参数属于 FuncType.Params；命名返回值位于 FuncType.Results。不要把字段筛选能力推广为完整的函数签名改写能力。

原地修改与返回值对旧代码有什么影响

FilterDecl 会原地裁剪传入的声明。若多个处理阶段共享同一棵 AST，一处过滤可能影响后续展示或分析。需要原始树和展示树时，可从同一份源文本分别解析，或使用明确的复制方案；简单复制一个节点结构体并不能自动复制其中所有指针与切片指向的节点。

返回的 bool 表示过滤后是否还存在声明名称，不是“所有白名单规则已在整棵树上执行完毕”的证明，也不是修改数量。只调用单条声明的 FilterDecl，调用方还需要处理 false 的结果；不能期待它替你从外层文件的 Decls 切片中移除对应项。

对依赖参数清洗的旧代码而言，继续增加回调条件并不能扩大遍历范围。应当拆开“保留哪些声明”和“怎样呈现签名”这两项职责，避免用一个 bool 同时表示声明保留、参数处理和输出正确。

展示签名和修改源码要采用不同策略

如果只想在文档中隐藏参数名称，优先生成独立的签名展示结构，再根据参数类型、分组数量和可变参数信息生成文本。对 name1、name2 共用一种类型的分组参数，不能简单把 Names 设为 nil 就认为保留了原来的参数个数。展示层需要按名称数量展开类型；原本未命名的参数组则按一个参数处理。

展示结构还应单独处理返回值、接收者与泛型类型参数。隐藏显示名称不等于删除参数，省略元数据也不应改变签名所表达的类型关系。

如果目标是重命名可执行源码中的参数，则必须同时考虑函数体引用、遮蔽、闭包捕获和命名返回值的使用。对同名 Ident 做全局字符串替换无法区分不同作用域。此类任务需要结合语义绑定信息选择准确对象，再安排改写；FilterDecl 不提供参数重命名协议。

怎样判断处理结果符合目标

阅读最小例子时，可以分别关注三个问题：Send 是否仍作为声明保留，secret 是否仍出现在参数列表，以及回调是否被错误地当成完整的标识符访问器。对这个例子，保留声明同时保留参数名正是预期语义。

扩展到自己的工具时，应明确输出契约：文档工具只需要隐藏显示名称，还是代码工具需要保持可编译的语义。前者围绕签名展示对象设计，后者围绕变量绑定与引用设计。不要只看格式化结果中某个词消失，就认定参数处理已经完整。

常见问题

改成 FilterFile 会过滤参数名吗？FilterFile 的文档同样排除了参数列表中的名称，扩大输入范围不会自动获得参数改写能力。

回调返回 false 就会删除所有子节点吗？不能把它理解为通用递归剪枝协议。声明是否保留、如何裁剪由接口规则决定，返回值也不能证明所有子节点都接受过回调。

能直接把参数名改成下划线吗？只改声明处可能使函数体里原有引用无法解析。仅用于展示时应处理展示模型；用于源码改写时需要同步处理准确的引用对象。

参考：FilterDecl 官方接口、声明过滤实现。本文围绕能力边界整理，没有将该行为包装为新版本发布或实测回归。