本文介绍在 JavaScript/TypeScript 运行时判断两个函数是否具有相同签名的可行方案，重点剖析基于 Function.prototype.toString() 的字符串匹配方法，并说明其局限性、适用场景及安全替代建议。
本文介绍在 javascript/typescript 运行时判断两个函数是否具有相同签名的可行方案，重点剖析基于 `function.prototype.tostring()` 的字符串匹配方法，并说明其局限性、适用场景及安全替代建议。
在 TypeScript 中，类型系统仅存在于编译期；一旦代码被编译为 JavaScript，所有类型信息（如参数名、类型注解、返回值声明）均被擦除。因此，运行时无法真正获取或比对“类型签名”——你无法像 fn.signature === constant.signature 那样进行类型级校验。但若目标是识别“结构上高度相似的函数”（例如都形如 (number) => number），可通过解析函数源码字符串实现近似检测。
✅ 可行方案：基于 fn.toString() 的正则匹配
JavaScript 规范要求 Function.prototype.toString() 返回函数的源码文本（对于原生函数返回 [native code]）。这使得我们能对箭头函数或普通函数的声明形式做轻量级模式识别：
完整的Galileo AI平台 TypeScript/JS SDK 参考，用于评估、观察和保护 GenAI 应用。适用于构建 Node.js 或 TypeScript 项目。
const constant = (number: number) => number;
class Context {
execute(fn: (...args: any[]) => any): void {
if (typeof fn !== 'function') return;
const fnStr = fn.toString();
// 匹配形如 "(number) =>" 或 "(n: number) =>" 的典型签名片段
const hasConstantLikeSignature = /(?:\(|\s)\s*number\s*(?::\s*number\s*)?\s*\)\s*=>/.test(fnStr);
if (hasConstantLikeSignature) {
console.warn('⚠️ 拒绝传入与 constant 签名高度相似的函数');
return false;
}
// 继续执行逻辑...
console.log('✅ 函数签名通过检查，执行中...');
}
}
// 测试用例
const ctx = new Context();
ctx.execute(constant); // ⚠️ 触发警告（匹配成功）
ctx.execute((x: number) => x * 2); // ⚠️ 可能误报（取决于命名和格式）
ctx.execute((value: string) => value); // ✅ 不匹配，正常执行
ctx.execute(function(x) { return x; }); // ❌ 不匹配（传统函数写法，toString 结果不同）? 注意正则设计要点：
- 使用非捕获组 (?:...) 和可选空格 \s* 提升鲁棒性；
- 允许参数带类型注解（如 n: number）或无注解（如 n），但核心关键词 number 作为语义锚点；
- 对箭头函数 => 前后空白兼容，避免因格式差异导致漏判。
⚠️ 关键限制与风险提示
- 不可靠性高：toString() 输出未标准化（尤其在压缩/混淆后），不同引擎或构建工具可能改变空格、换行、参数重命名（如 Terser 会将 number 缩为 n），导致匹配失效或误判。
- 语义不等价：(n: number) => string 和 (x: number) => number 字符串均含 number，但签名完全不同——正则无法区分参数类型与返回类型。
- 无法覆盖所有语法变体：function foo(n) { return n; }、const f = function(n) { return n; }; 等写法 toString() 输出不含 =>，需额外规则，维护成本陡增。
- TypeScript 类型无关：该方法完全脱离 TS 类型系统，TS 编译器不会参与运行时校验，也无法提供类型安全提示。
✅ 更健壮的工程化建议
| 场景 | 推荐做法 |
|---|---|
| 强约束需求（禁止特定行为） | 将 constant 设计为唯一实例（Symbol 或私有类），用 === 严格比较引用： if (fn === constant) throw new Error('constant is forbidden'); |
| 需动态策略分发 | 使用策略注册表 + 显式标识符： fn.__signatureId = 'identity_number_to_number';，运行时查表而非解析代码 |
| 类型即契约（推荐 TS 原生方式） | 在编译期拦截：定义专用类型 type ForbiddenFn = typeof constant;，并在参数中排除： execute<T extends (...args: any[]) => any>(fn: T & Exclude<T, ForbiddenFn>)（需配合泛型+条件类型，但无法 100% 防御类型断言绕过） |
总结
运行时函数签名检测本质是「在无类型上下文里模拟类型判断」，属于权衡后的妥协方案。toString() + 正则虽简单可用，但应仅用于开发辅助、日志审计等非关键路径。生产环境强烈建议回归设计源头：通过接口契约、显式标记或引用比较替代模糊的字符串匹配，兼顾可维护性与可靠性。TypeScript 的真正优势在于编译期保障——善用 strictFunctionTypes、自定义类型守卫（isConstantFn(fn): fn is typeof constant）等特性，才能构建更坚实的安全边界。
