我在 TypeScript 里给函数参数标了个空对象大括号类型、想表示只收一个对象,结果传数字、传字符串、传布尔值进去编译器全都不报错照单全收,我盯着那对空大括号愣了半天,最后才搞懂这个看着像空对象的类型,实际表示的是除了 null 和 undefined 之外几乎任何值

这是一次让我把 TypeScript 里"{} 类型"这件事,从"表示一个空对象 / 任意对象",重新理解成"表示除了 null/undefined 之外几乎任何值"的事故。我给函数参数标了个空对象大括号类型 {},想表示"只收一个对象"。结果传数字、传字符串、传布尔值进去,编译器全都不报错、照单全收。我盯着那对空大括号愣了半天,最后才搞懂:这个看着像"空对象"的类型,实际表示的是"除了 null 和 undefined 之外几乎任何值"。这篇就把这次"{} 类型拦不住非对象"的事故,从头到尾复盘一遍。

故障现场:标了 {} 想要对象,结果什么都能传

我写了个函数,本意是它只接收一个"对象"(任意结构的对象都行,但至少得是个对象、不能是基本类型)。我很自然地把参数类型标成了 {}——在我的直觉里,{} 不就是"一个空对象",引申为"任意对象"嘛。我以为这样就能限制住:只准传对象,传数字、字符串这些就该报错。

可写着写着我发现不对:我把 42、"hello"、true 这些明显不是对象的值传进去,编译器一个错都不报。这道我以为加上了的"只准传对象"的类型约束,形同虚设。我一开始以为是我哪里写错了,反复确认参数类型就是 {};又怀疑是 strict 没开,检查也开着。直到我去查 {} 类型到底是什么意思,才彻底明白根因——在 TypeScript 里,{} 类型不表示"空对象",而表示"任何非 null、非 undefined 的值"。原因在于 TS 的结构化类型:{} 作为类型,意思是"一个没有任何必需属性的类型"——它对值没有提出任何要求;而 TS 判断"一个值能不能赋给某类型",看的是"这个值有没有满足该类型要求的所有属性"。既然 {} 什么属性都不要求,那么任何值——数字、字符串、布尔、对象、数组、函数——都"满足了它的零要求",都能赋给 {}(唯独 null 和 undefined 不行,因为它们连访问属性都会崩、不被认为是"有属性的值")。所以 {} 几乎等价于"除了 null/undefined 之外的一切",是一个极其宽泛、几乎不设防的类型。我以为 {} 的"空"是"一个空的对象"(很窄),其实它的"空"是"空的约束、零要求"(因而极宽)。

// 我的本意: 只接收对象
function process(data: {}) {     // ★ 以为 {} 表示"对象", 其实不是
    // ...
}

// 结果: 什么都能传进来, 编译器全不报错!
process(42);          // ✓ 不报错(我以为该报错)
process("hello");     // ✓ 不报错
process(true);        // ✓ 不报错
process([1, 2, 3]);   // ✓ 不报错
process({ a: 1 });    // ✓ 不报错
process(() => {});    // ✓ 不报错
process(null);        // ✗ 这个才报错(null 不行)
process(undefined);   // ✗ 这个才报错(undefined 不行)

// 真相: {} 类型 = "任何非 null/非 undefined 的值"
//   结构化类型下, {} 表示"不要求任何属性", 任何值都满足"零要求"
//   所以 number/string/boolean/对象/数组/函数 都能赋给 {}
//   {} 的"空"不是"空对象"(窄), 而是"空约束、零要求"(因而极宽)

问题被钉死在这个认知错位上:我以为 {} 这个类型,字面看是"一个空对象"、引申为"任意对象",是个比较窄的、能把基本类型挡在外面的约束。但在 TS 的结构化类型体系里,{} 表示的是"一个不要求任何属性的类型"——它对值没有任何要求,于是"除了 null/undefined 之外的任何值"都满足它,它实际上是一个极其宽泛、几乎不挡任何东西的类型。我把"空对象(没有内容的对象)"和"空约束(没有要求的类型)"混为一谈——前者是窄的(只匹配空对象那一种),后者却是宽的(零要求等于谁都符合)。在结构化类型里,"要求得越少,符合的值越多";{} 要求为零,所以符合的值几乎是全部。我以为我画了一个小圈把对象圈进来,其实我画的是一个几乎涵盖一切的大圈。我以为"空"代表"很少、很窄",可在"约束"的语境里,"空的约束"恰恰意味着"放行一切"。

第一件事:想明白 {} 是"零约束",约束越少匹配越宽

把这次事故彻底想清楚,关键是理解TypeScript 是结构化类型系统:一个值能否赋给某个类型,取决于"这个值是否具备该类型要求的所有成员";一个类型"要求"得越多(属性越多、约束越严),能满足它的值就越少(类型越窄);反之,要求得越少,能满足的值就越多(类型越宽)。{} 作为类型,是"要求最少"的对象类型——它不要求任何属性;于是任何"非空(非 null/undefined)"的值都满足它的零要求,{} 因此几乎等价于"除 null/undefined 外的一切",是个极宽的类型,起不到"限制为对象"的作用。

这就引出了"到底想表达什么、就用什么类型":如果你想表示"任意对象(但不能是基本类型/null)",用 object(它表示"非基本类型的值",能把 number/string/boolean 挡在外面);如果你想表示"任意键值对的对象"且后续要按 key 访问,用 Record<string, unknown>;如果你想表示"真正的空对象(不能有任何属性)",得用更别扭的写法(如 Record<string, never>),而绝不是 {};如果你想表示"任意值但要先收窄才能用",用 unknown(它比 {} 更安全,连访问属性前都强制你先判断)。关键认知是:在类型系统(以及一切"用约束来界定范围"的场景)里,"约束的多少"和"覆盖范围的大小"是反比的——约束越少,放进来的越多;一个"看起来什么都没写"的约束,往往不是"什么都不匹配",而是"什么都匹配"。要表达"限制"的意图,必须写出真正能起到限制作用的、有实质要求的约束,而不是一个空的、零要求的形式。

// 按"到底想表达什么"选对类型:

// 想要: 任意对象(挡住 number/string/boolean/null/undefined)
function process(data: object) {}   // ✓ object 表示非基本类型的值
process(42);                        // ✗ 报错! number 不是 object(正合我意)
process({ a: 1 });                  // ✓
process([1, 2]);                    // ✓ 数组也是 object(如要排除得另判)

// 想要: 任意键值对象, 后续按 key 访问
function handle(opts: Record) {
    for (const k in opts) { /* opts[k] 是 unknown, 用前要收窄 */ }
}

// 想要: 真正的空对象(不能有任何属性)—— 不是 {}, 要用 never 值
type EmptyObject = Record;

// 想要: 任意值, 但强制用前先收窄(比 {} 更安全)
function safe(x: unknown) {
    if (typeof x === "object" && x !== null) { /* 这里才当对象用 */ }
}

// 对比四者的"宽窄":
//   unknown  ⊇  {}  ⊇  object  ⊇  具体接口
//   (unknown 最宽含 null/undefined; {} 次宽; object 只非基本类型; 接口最窄)

想通这一层,我才明白自己错在哪:我把 {} 的"空"误解成了"空对象(很窄)",而它实际是"空约束(因而极宽)"——在结构化类型里,不要求任何属性的类型,等于谁都符合。我想用它"限制为对象",可它恰恰是个几乎不设限的类型,把我想挡住的基本类型全放了进来。根治之道,是按"我到底想表达什么"选对类型:要"对象"用 object、要"键值对"用 Record、要"任意值且强制收窄"用 unknown,而几乎永远不该用 {} 当"对象"。不是凭直觉以为"空就是窄",而是认清空的约束等于最宽的范围、用有实质要求的类型去真正表达限制。

第二件事:正解——按意图选对类型,别用 {} 当"对象"

找到根因,正解就清晰了:按"到底想表达什么"选类型,几乎永远别用 {} 当"对象"——要"任意对象(挡住基本类型)"用 object;要"任意键值对象、后续按 key 访问"用 Record<string, unknown>;要"真正的空对象"用 Record<string, never>;要"任意值但强制用前先收窄"用 unknown(比 {} 安全);并开启 lint 规则(typescript-eslint 的 ban-types)禁用裸 {}。

// 错误: 用 {} 当"对象", 几乎什么都放进来
function process(data: {}) {}              // ✗ number/string/boolean 都能传

// 正解1: 任意对象 → object(挡住基本类型)
function process2(data: object) {}         // ✓ 42/"x"/true 报错; 对象/数组通过

// 正解2: 任意键值对象 + 按 key 访问 → Record
function handle(opts: Record) {
    const v = opts["key"];                 // v: unknown, 用前要收窄
    if (typeof v === "string") use(v);
}

// 正解3: 真正的空对象(不能有属性) → Record
function onlyEmpty(o: Record) {}
onlyEmpty({});        // ✓
onlyEmpty({ a: 1 });  // ✗ 报错(正确拦下)

// 正解4: 任意值但强制收窄 → unknown(最安全的"任意")
function safe(x: unknown) {
    // 不收窄不能用, 编译器逼你先判断, 比 {} 安全得多
    if (x && typeof x === "object") { /* 当对象用 */ }
}

// 正解5: lint 禁用裸 {} —— 从源头拦住误用
// .eslintrc: "@typescript-eslint/ban-types": ["error"]  // {} 会被提示改用 object/unknown

这套做法的精髓,是先想清楚"我到底要约束成什么",再选一个真正能起到这个约束作用的类型,而不是凭"看着像"用一个零约束的 {}。object 表达"非基本类型"、Record 表达"键值结构"、unknown 表达"任意但需收窄"、具体接口表达"有这些字段"——它们都有实质的要求,因而能真正限制住值;而 {} 没有任何要求,等于不设限。再用 lint 把裸 {} 禁掉,从源头杜绝误用。不是用一个空形式去假装约束,而是用有实质要求的类型去真正表达你想要的限制。

【表达"对象/任意值"类型, 我现在认死的几条】

1. {} 类型不是"空对象", 而是"任何非 null/undefined 的值"(极宽)

2. 结构化类型: 约束越少匹配越宽; {} 零约束 → 几乎谁都符合

3. number/string/boolean/数组/函数 都能赋给 {}, 它拦不住基本类型

4. 要"任意对象、挡住基本类型" → 用 object

5. 要"任意键值对象、按 key 访问" → 用 Record

6. 要"任意值但强制收窄" → 用 unknown(比 {} 安全)

7. 真正空对象用 Record; lint 禁用裸 {}

第三件事:其他"空形式被误当成强约束、实则毫不设防"的同类坑

顺着"一个看起来'空/没写什么'的约束,被误以为很严,实则毫不设防"这条线,我把同类的坑都排查了一遍:

第一个,any 比 {} 更彻底地不设防。标了 any 等于关掉该处的一切类型检查,什么都能传、什么都能调,连 null 访问都不拦;它是比 {} 还宽的"零约束"。

第二个,空的接口 interface Foo {} 等价于 {}。以为定义了个类型在限制,其实它没要求任何属性,和 {} 一样几乎谁都符合。

第三个,正则 / 校验规则写得过于宽松。校验用了个"看着像在校验"却几乎匹配一切的规则(如 .*),等于没校验,脏数据照进。

第四个,权限/过滤规则为空被当成"严格"。配置里规则列表为空,有的系统理解成"放行一切",而你以为是"什么都不放"——空规则的含义全看默认是 allow 还是 deny。

第四件事:{} / object / Record / unknown / any——一张对照表

我把几个最容易混的"宽泛类型"摆在一起对比,核心看"能挡住什么、该用在哪":

看清这张表,选择就有谱了:要"任意对象"用 object(挡住基本类型);要"键值对"用 Record;要"任意值"用 unknown(强制收窄、最安全);已知结构用具体接口;{} 和 any 几乎都该避免。我这次踩坑,正是把 {} 当成了"对象",而它其实几乎不挡任何东西。这几个类型的"宽窄"差别巨大,望文生义(以为 {} 是空对象=很窄)就会选错。

第五件事:我曾经对 {} 类型想当然的几个误区

这次事故也把我对宽泛类型的一堆"想当然"照了个底朝天:

这些误区的根子是同一个:我把"空对象(没有内容的对象,一种很窄的值)"和"空约束(没有要求的类型,一种很宽的范围)"混为一谈,望文生义地以为 {} 的"空"代表"窄"。但在以"约束界定范围"的类型系统里,逻辑恰好相反:你要求得越少,符合你的就越多;一个不提任何要求的类型,放进来的是几乎一切。把"形式上的空"误读成"范围上的窄",而忽略了约束与范围的反比关系,是这类"以为限制了其实没限制"的共同根源。

第六件事:标类型、排查"标了类型却什么都能传"时,我现在的自检习惯

现在每当我标一个"宽泛"的类型、或排查"明明标了类型却什么都能传进来",我都会先按这张图问自己:

这张图的精髓,是"标了类型却什么都能传先看是不是 {}/空接口/any 这种零约束;按真实意图改用 object/Record/unknown/具体接口"。设计就按意图选有实质要求的类型(object/Record/unknown/接口)、lint 禁用裸 {}、排查就看那个宽泛类型是不是零约束的 {} 或空接口。这套习惯,让我从"凭直觉用 {} 表示对象"变成了"先想清要约束成什么再选类型"——核心始终是:TypeScript 是结构化类型系统,一个值能否赋给某类型取决于这个值是否具备该类型要求的所有成员;一个类型要求得越多(属性越多约束越严)能满足它的值就越少(类型越窄),反之要求得越少能满足的值就越多(类型越宽);{} 作为类型不表示空对象而表示一个没有任何必需属性的类型——它对值没有提出任何要求,而 TS 判断值能不能赋给某类型看的是这个值有没有满足该类型要求的所有属性,既然 {} 什么属性都不要求那么任何值(数字字符串布尔对象数组函数)都满足了它的零要求都能赋给 {},唯独 null 和 undefined 不行,所以 {} 几乎等价于除 null/undefined 外的一切、是个极其宽泛几乎不设防的类型起不到限制为对象的作用;{} 的空不是空对象(很窄)而是空约束零要求(因而极宽);要按到底想表达什么选类型:想要任意对象挡住基本类型用 object,想要任意键值对象后续按 key 访问用 Record,想要真正的空对象不能有任何属性用 Record,想要任意值但用前先收窄用 unknown(它比 {} 更安全连访问属性前都强制你先判断);关键认知是在类型系统以及一切用约束来界定范围的场景里约束的多少和覆盖范围的大小是反比的——约束越少放进来的越多,一个看起来什么都没写的约束往往不是什么都不匹配而是什么都匹配,要表达限制的意图必须写出真正能起到限制作用的有实质要求的约束而不是一个空的零要求的形式。

我立下的几条规矩

这场"{} 类型拦不住非对象"的事故,换来了我标类型时,刻进骨子里的几条铁律:

1. {} 类型不是"空对象",而是"任何非 null/undefined 的值"(极宽)。
2. 结构化类型:约束越少匹配越宽;{} 零约束 → 几乎谁都符合。
3. number/string/boolean/数组/函数 都能赋给 {},它拦不住基本类型。
4. 要"任意对象、挡住基本类型" → 用 object。
5. 要"任意键值对象、按 key 访问" → 用 Record<string, unknown>。
6. 要"任意值但强制收窄" → 用 unknown(比 {} 安全);真正空对象用 Record<string, never>。
7. lint 禁用裸 {} 和 any;空接口同 {},别拿它假装约束。

附:我现在表达"宽泛对象/任意值"的类型选型小抄与守卫

这是我现在表达宽泛类型固定套的选型小抄和运行时守卫——把这次踩坑的教训(别用 {}、按意图选 object/Record/unknown、用 unknown 时配收窄守卫)固化成可复用的代码,让"{} 拦不住非对象"那种坑再不会埋进代码:

// 选型小抄: 想表达什么 → 用什么
// 任意对象(挡基本类型)        → object
// 任意键值对象(按 key 访问)   → Record
// 真正的空对象(无任何属性)    → Record
// 任意值(用前强制收窄, 最安全) → unknown
// 已知结构                    → 具体 interface / type
// (几乎永远别用: {} 和 any)

// 配套的运行时类型守卫: 把 unknown 安全地收窄成"对象"再用
function isObject(x: unknown): x is Record {
    return typeof x === "object" && x !== null && !Array.isArray(x);
}

function handle(input: unknown) {            // 入口用 unknown(比 {} 安全)
    if (!isObject(input)) {
        throw new Error("expected an object");  // 不是对象当场拦下
    }
    // 这里 input 已被收窄为 Record, 可安全按 key 访问
    const name = input["name"];
    if (typeof name === "string") use(name);
}

// 解析外部数据(本质都是 unknown): 别标 any/{}, 用 unknown + 校验
const data: unknown = JSON.parse(raw);       // JSON.parse 返回 any, 立刻收成 unknown
if (isObject(data) && typeof data.id === "number") {
    process(data.id);
}

这套小抄把我这次的教训钉死在了选型里:按"想表达什么"对号入座选类型(任意对象 object、键值对 Record、任意值 unknown、已知结构具体接口),几乎永远不用 {} 和 any;入口处不确定的值用 unknown(强制收窄)而非 {},再配 isObject 这类类型守卫把它安全地收成对象、不是对象就当场拦下;解析外部数据(JSON.parse 等)也立刻收成 unknown + 校验。这样,类型真正起到了限制和引导的作用、运行时也有守卫兜底,而不再是当初那个"标了 {} 却把数字字符串全放进来"的不设防局面。把"认清约束与范围成反比、用有实质要求的形式表达限制"这个道理,沉淀成类型选型的固定小抄,这是我对这次"{} 拦不住非对象"最实在的交代——毕竟,想让一道门只放对象进来,得给它装一把真能认对象的锁,而不是干脆把门敞开还以为自己上了锁。

写在最后

回头看,这场由"{} 类型"引发的"什么都能传"事故,真正教给我的,远不止"改用 object"这一个技巧。它让我对"'空'这个词,在不同的语境里,意思可能截然相反:在'内容'的语境里,'空'意味着'什么都没有、很少、很窄';但在'约束/规则/条件'的语境里,'空'却意味着'没有任何要求、因而什么都符合、极宽';我们的直觉习惯了前一种'空=少',于是看到一个'空空如也'的约束,就想当然地以为它很严、能挡住很多,却没意识到'没有要求'恰恰等于'放行一切'",有了一次刻骨的体会。我栽跟头,是因为我把"空约束(没有任何要求的类型)",望文生义地误读成了"空对象(没有内容的、很窄的一种值)"——我看到 {} 这对空大括号,脑子里浮现的是"一个空荡荡的对象",觉得它很具体、很窄;我没意识到,作为类型,这对空大括号说的不是"一个空对象",而是"我对你没有任何要求"——而在"谁能符合我"这件事上,"没有任何要求"意味着"所有人都符合";于是我以为画了一个小圈把对象圈进来,实际画的是一个几乎涵盖一切的大圈,把我想挡在外面的数字、字符串,全都收了进来。这让我领悟到一个关于"约束与范围的反比、空的两种含义"的深刻认知:凡是用"条件/约束/规则"来界定一个范围的地方(类型、过滤、权限、校验、查询),"约束的强度"和"它覆盖的范围"是反比的:你要求得越多、条件越严,符合的越少、范围越窄;你要求得越少、条件越松,符合的越多、范围越宽;而"没有任何约束"这个极端,对应的不是"空集(什么都不符合)",而是"全集(什么都符合)";所以一个"形式上空空如也"的约束,绝不能想当然地当成"很严、范围很小"——它极可能是"毫不设防、放行一切";要表达"我要限制"的意图,必须写出有实质要求的、真正能筛掉东西的约束,而不是一个看起来在约束、实则零要求的空壳;判断一个约束严不严,不看它"写得多不多",而看它"实际能挡住多少"。这给了我一种看待"一切'用约束界定范围'之事"时的清醒:每当我写下一个类型、一条过滤规则、一个校验条件、一份权限策略时,要追问"这个约束真的有实质要求吗?还是一个空的、零要求的形式?在'谁能通过'这件事上,它实际放行的是很少,还是几乎一切?我想限制的东西,它真的挡住了吗"——用有实质要求的约束去真正表达限制,警惕'空约束=放行一切'这个反直觉的陷阱;"认清约束与范围成反比、空的约束等于最宽的范围、用有实质要求的形式表达限制",是用对 TypeScript 类型、也是写对一切约束规则的关键。认清 {} 是零约束几乎匹配一切、约束越少范围越宽、按意图选 object/Record/unknown——这,是我用一次"标了 {} 却什么都能传"的事故,换来的、关于 TypeScript、也关于"空"在约束语境里意味着"宽"的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次想用 {} 表示"对象"时,先停一秒想想"它其实几乎什么都放行,我是不是该用 object 或 unknown?",那我对着那个"标了类型却把数字字符串全收进来"的函数发懵的大半天,就值了。

—— 别看了 · 2026