TypeScript 编译后不保留类型信息，因此无法在运行时直接比较函数签名；本文介绍基于 Function.toString() 的字符串模式匹配方案，并分析其局限性，同时提供更健壮的替代设计思路。
typescript 编译后不保留类型信息，因此无法在运行时直接比较函数签名；本文介绍基于 `function.tostring()` 的字符串模式匹配方案，并分析其局限性，同时提供更健壮的替代设计思路。
在 TypeScript 中，类型系统仅存在于编译期（design time），所有类型注解（如 (number: number) => number）都会被擦除，生成的标准 JavaScript 代码中不存在签名元数据。这意味着：你无法通过 instanceof、typeof 或反射 API 原生判断两个函数是否“具有相同签名”——因为签名本身不是运行时对象属性。
❌ 为什么 fn instanceof constant 不可行？
instanceof 检查的是原型链继承关系，而普通函数（包括箭头函数）并非由另一个函数实例化而来，constant 是一个函数值，不是构造器。因此该表达式语法错误且语义无效：
const constant = (n: number) => n;
// ❌ Runtime error: "Right-hand side of 'instanceof' is not callable"
if (fn instanceof constant) { /* ... */ }✅ 可行方案：基于 Function.prototype.toString() 的启发式匹配
虽然不完美，但最常用（且唯一无需额外运行时注解的）方法是将函数转为字符串并正则匹配参数名与返回结构：
Galileo TypeScript sdk
下载
完整的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) =>" 或 "(number: number) =>" 的签名片段
const hasConstantSignature = /\(number(?::\s*number)?\)\s*=>/.test(fnStr);
if (hasConstantSignature) {
console.warn('Rejected: function matches forbidden signature of `constant`');
return false;
}
// ✅ Proceed with safe execution
console.log('Executing allowed function');
}
}
const ctx = new Context();
ctx.execute(constant); // → rejected
ctx.execute((x: string) => x.length); // → allowed
ctx.execute((n) => n * 2); // → allowed（参数名非 "number"，不匹配）⚠️ 重要注意事项：
- toString() 行为受规范约束，但不同引擎可能有细微差异（如空格、换行、参数类型省略）；
- 箭头函数、具名函数、方法写法生成的字符串格式不完全一致；
- 仅匹配源码文本特征，非真实类型语义（例如 (n: number) => number 和 (x: number) => number 都合法，但正则需兼顾变量名灵活性）；
- 不可用于生产环境的关键校验逻辑——它易被绕过（如 eval 构造、IIFE 匿名化、Babel 转译后参数重命名）。
✅ 更健壮的替代方案（推荐）
与其在运行时“猜测签名”，不如从架构层面规避风险：
1. 使用标记接口 + 显式标识
interface ForbiddenConstantFn extends Function {
__forbiddenConstant?: true;
}
const constant = Object.assign(
(n: number) => n,
{ __forbiddenConstant: true } as ForbiddenConstantFn
);
class Context {
execute(fn: Function): void {
if ('__forbiddenConstant' in fn && fn.__forbiddenConstant === true) {
throw new Error('Forbidden constant function detected');
}
}
}2. 类型安全的函数注册表（编译期+运行时双重保障）
type AllowedFn = ((...args: unknown[]) => unknown) & { __kind?: 'allowed' };
const createAllowedFn = <T extends (...args: any[]) => any>(fn: T): AllowedFn & T => {
const wrapped = fn as AllowedFn & T;
wrapped.__kind = 'allowed';
return wrapped;
};
const safeFn = createAllowedFn((x: string) => x.toUpperCase());
ctx.execute(safeFn); // ✅ OK
ctx.execute(constant); // ❌ fails type-check *and* runtime check3. （最佳实践）重构为策略模式，避免动态函数注入
abstract class ExecutionStrategy {
abstract run(...args: unknown[]): unknown;
}
class ConstantStrategy extends ExecutionStrategy {
run(n: number): number { return n; }
// 显式禁止外部使用此策略实例
private constructor() { super(); }
static forbid() { throw new Error('ConstantStrategy is disallowed'); }
}总结
- 运行时无真正“签名比较”：TypeScript 类型在 JS 运行时不可见；
- toString() + 正则是快速验证的权宜之计，适合开发/调试，切勿用于安全敏感场景；
- 推荐采用显式标记（Symbol 或私有属性）、函数包装或策略抽象等设计先行的方式，兼顾类型安全与运行时可控性；
- 若业务强依赖函数契约，应推动 API 设计向声明式、可枚举、可注册的方向演进，而非依赖脆弱的字符串解析。
