函数参数与外部作用域变量同名是否属于不良编程实践？

这个问题没有非黑即白的答案，核心判断标准是函数本身的职责边界。变量遮蔽（即内层作用域声明同名变量覆盖外层作用域同名变量的语法特性）本身是JS/TS的合法特性，用得好不好全看场景：

• 对于完全不依赖外部状态的纯工具函数，参数和外部变量同名完全是合理写法，不属于坏实践。比如你示例里的sortFilesChronologically，本身是个通用排序函数，设计目标就是接收一个文件列表返回排序后的结果，根本不会去引用组件作用域里的files状态，这时候参数名就叫files反而最符合语义——读代码的人一眼就知道这个位置要传的是待排序的文件列表，没必要为了避开外部同名特意改成冗余的名字。
• 对于本身作为闭包、需要读写外部作用域状态的业务函数（比如示例里的handleFilesChange），就不建议参数和外部状态同名。这种场景下的变量遮蔽很容易埋坑：如果你后续维护时忘了参数和外部状态重名，想在函数内部读取外部的files状态，实际拿到的会是参数值，这类逻辑bug排查起来往往要花不少时间。你现在给参数起名uploadedFiles的处理方式就非常妥当，既明确了参数本身的语义（是新上传的文件，不是组件存的全量文件状态），也从根源上避免了遮蔽带来的混淆。

你担心的「后续修改函数引用外部同名变量引发冲突」的问题，本质上可以靠明确函数职责提前规避：

纯工具函数从设计上就不该依赖外部可变状态，只要守住这个边界，就算参数和外部变量重名，也永远不会出现你担心的逻辑冲突；如果是和业务绑定的闭包函数，从一开始就给参数加上明确的语义限定词做区分，不要和外部状态重名，就不会踩坑。

对应示例代码如下：

// 组件作用域的全局状态，命名为files
let files: File[] = [];

// 作为闭包的事件处理函数，参数用带语义限定的uploadedFiles，不和外部状态重名
function handleFilesChange(uploadedFiles: File[]) {
    files = sortFilesChronologically(files, "desc");
}

// 纯工具函数，参数直接用files，和外部状态同名无影响
function sortFilesChronologically(files: File[], direction: "asc" | "desc" = "asc") {
    return [...files].sort((file1, file2) => {
        const file1Time = new Date(file1.lastModified).getTime();
        const file2Time = new Date(file2.lastModified).getTime();
        const dirModifier = direction === "asc" ? 1 : -1;
        return dirModifier * (file1Time - file2Time);
    });
}

内容的提问来源于stack exchange，提问作者Grant Pitt