示例工程【免费下载链接】type-challengesCollection of TypeScript type challenges with online judge项目地址https://gitcode.com/GitHub_Trending/ty/type-challenges点击查看免费下载本文以 type-challenges 仓库中编号 00005、难度为 extreme 的题目《Get Readonly Keys》为核心讲解如何实现一个泛型工具类型GetReadonlyKeysT它能够从任意对象类型 T 中筛选出所有readonly修饰的键并以联合类型返回。读者在读完本文后将掌握映射类型修饰符的保留与剥离规则、readonly在类型兼容性中的特殊行为以及借助Equal做类型同一性判断的高阶技巧从而能够独立完成这一类区分修饰符的类型级编程题目。题目背景一道被标记为 extreme 的对象键工具题本题目位于仓库的 questions/00005-extreme-readonly-keys 目录下由仓库作者 Anthony Fuantfu编写。从 info.yml 可以看到它的元信息标题Get Readonly Keys难度extreme地狱级标签utils、object-keys题目虽短却触及 TypeScript 类型系统中最刁钻的角落之一——readonly修饰符。在绝大多数赋值兼容性检查中TypeScript 会无视只读修饰符这使得判断某个键是否只读变成了一道真正的地狱难度题。题目要求返回对象中只读键的联合类型根据 README.pt-BR.md 的描述我们需要实现一个泛型类型GetReadonlyKeysT它返回对象 T 中所有只读键组成的联合类型。原文给出的示例interface Todo { readonly title: string readonly description: string completed: boolean } type Keys GetReadonlyKeysTodo // expected to be title | description在这个Todo接口中title与description被readonly修饰而completed是可变的因此GetReadonlyKeysTodo的期望结果是title | description。题目目录下的 template.ts 给出了解题起点——一个占位的anytype GetReadonlyKeysT any我们需要用真正的类型逻辑替换掉这个any。测试用例理解题目的完整边界真正定义题目验收标准的是 test-cases.ts 中的断言import type { Equal, Expect } from type-challenges/utils type cases [ ExpectEqualtitle, GetReadonlyKeysTodo1, ExpectEqualtitle | description, GetReadonlyKeysTodo2, ] interface Todo1 { readonly title: string description: string completed: boolean } interface Todo2 { readonly title: string readonly description: string completed?: boolean }两个用例分别验证了两类边界情况用例输入类型期望输出考察点Todo1仅title只读其余可变title必须把可变的description、completed正确排除Todo2title、description只读completed?为可选可变title \| description必须正确处理可选键不能被可选的completed?干扰特别是 Todo2 中的completed?: boolean是一个可选但可变的键——它既有?可选修饰符又没有readonly。一个合格的解法必须能穿透可选的干扰准确识别只读修饰符。前置知识三个必须掌握的类型机制1. 同态映射类型会保留修饰符在 TypeScript 中形如{ [P in K]: T[P] }其中K extends keyof T的映射类型被称为同态映射类型homomorphic mapped type它会自动保留源类型属性上的readonly与可选修饰符。这正是内置工具类型Pick、Readonly等得以工作的底层机制。2.-readonly与-?显式剥离修饰符映射类型允许通过加减运算符显式控制修饰符-readonly剥离只读修饰符把属性变为可变-?剥离可选修饰符把属性变为必选。因此{ -readonly [P in K]: T[P] }无论源属性原本是否只读产出的属性都一定是可变的。3.readonly在赋值兼容性中被忽略这是本题最核心的陷阱TypeScript 的结构类型系统在检查可赋值性时不区分{ readonly a: string }与{ a: string }。也就是说只读对象可以赋给可变类型反之亦然。因此诸如K extends keyof T之类的普通条件类型判断完全无法感知readonly的存在。这正是题目被标记为 extreme 的根本原因。解题核心用 Equal 做类型同一性判断既然extends无法区分只读与可变就必须借助更严格的类型相等测试。仓库在 utils/index.d.ts 中提供了现成的Equal工具类型export type EqualX, Y (T() T extends X ? 1 : 2) extends (T() T extends Y ? 1 : 2) ? true : falseEqual的原理是把 X、Y 分别放进泛型函数签名的条件类型中利用条件类型在泛型函数中的延迟求值与参数位置的逆变检查对两个类型做比extends严格得多的同一性比较。它能够识别readonly修饰符的差异。解题思路可以概括为三步遍历T的所有键K对每个键构造两个影子类型一个保留该键原本的只读状态{ [P in K]: T[P] }一个强制剥离只读{ -readonly [P in K]: T[P] }用Equal比较两者若相等说明该键本来就是可变的输出never若不相等说明原键带readonly修饰符输出K。完整实现与逐行拆解基于上述思路一个通过全部测试用例的实现如下import type { Equal } from type-challenges/utils type GetReadonlyKeysT { [K in keyof T]-?: Equal { [P in K]: T[P] }, { -readonly [P in K]: T[P] } extends true ? never : K }[keyof T]逐行拆解[K in keyof T]-?遍历 T 的所有键。-?的作用是剥离映射结果的可选修饰符——因为 Todo2 中completed?是可选的如果不加-?条件为真时输出的never会与可选修饰符纠缠导致整个对象的取值结果被undefined污染无法得到干净的联合类型。这一点正是 Todo2 用例存在的原因。{ [P in K]: T[P] }同态映射保留键 K 在 T 上的真实修饰符。若 K 原本只读此处即为只读属性若 K 原本可变此处即为可变属性。{ -readonly [P in K]: T[P] }显式剥离readonly得到对应的恒为可变版本。EqualA, B extends true ? never : K对只读键A保留只读与B剥离只读在Equal看来不相等返回K对可变键A与B完全相同返回never。末尾的[keyof T]对映射结果整体取索引把所有K收集为联合类型同时自动剔除never。用题目中的 Todo 类型代入验证interface Todo { readonly title: string readonly description: string completed: boolean } type Keys GetReadonlyKeysTodo // title | description ✓对title键Equal{ readonly title: string }, { title: string }结果为false输出title对completed键两个影子类型都是{ completed: boolean }Equal结果为true输出never最终被[keyof T]索引后自然消失。测试用例的通过逻辑回到 test-cases.ts上述实现会得到GetReadonlyKeysTodo1titledescription、completed均为可变键被排除GetReadonlyKeysTodo2title | descriptioncompleted?虽是可选键但-?已消除可选修饰符干扰且它本身可变被正确排除。两条断言ExpectEqual...均由Equal精确校验编译期通过即表示解法正确。在仓库中运行与验证本仓库是一个 pnpm workspace见根目录 package.jsonpackageManager: pnpm8.12.1测试用到的type-challenges/utils通过workspace:*协议直接引用 utils 目录其类型定义即 utils/index.d.ts。验证方式在 template.ts 中填入你的实现然后在仓库根目录执行pnpm install npx tsc --noEmit项目根 tsconfig.json 继承了 tsconfig.base.jsonstrict: true、lib: ESNext、module: commonjs配合 test-cases.ts 中ExpectEqual...的断言写法只要类型不匹配编译就会直接报错全部断言通过即代表GetReadonlyKeysT实现正确。延伸思考为何不能用普通的 extends 判断一个常见的错误解法是// ❌ 错误示范readonly 在赋值兼容性中被忽略 type GetReadonlyKeysT { [K in keyof T]: { readonly [P in K]: T[P] } extends { [P in K]: T[P] } ? K : never }[keyof T]由于{ readonly a: string }与{ a: string }在结构类型系统中互相可赋值上面的extends永远为true结果会把所有键都当成只读键返回完全错误。这正是Equal与普通extends的本质区别前者做的是同一性检查后者做的是可赋值性检查。理解了这一点也就理解了这道 extreme 题目的全部精髓——类型系统的修饰符语义只有在最严格、最深层的检查中才会显形。赞分享示例工程【免费下载链接】type-challengesCollection of TypeScript type challenges with online judge项目地址https://gitcode.com/GitHub_Trending/ty/type-challenges点击查看免费下载相关推荐Matter (connectedhomeip) 持久化键值存储 KVS APIpersistent-storage 示例的构建、运行与平台实现差异Matter connectedhomeip 持久化键值存储 KVS APIpersistent storage 示例的构建、运行与平台实现差异 本文以 Ma示例工程Kubernetes Goat 场景一实战从 .git 暴露到 TruffleHog 检测代码库中的敏感密钥Kubernetes Goat 场景一实战从 .git 暴露到 TruffleHog 检测代码库中的敏感密钥 本文围绕 Kubernetes Goat 的第一示例工程golang-jwt/jwt v5 迁移指南解析选项、Claims 接口重构与错误模型升级inngest 仓库实战golang jwt/jwt v5 迁移指南解析选项、Claims 接口重构与错误模型升级inngest 仓库实战 本指南以 golang jwt/jwt示例工程上一篇抖音网页版直播数据抓取实战告别复杂配置一键获取实时弹幕下一篇Windows远程桌面多用户连接免费方案RDP Wrapper Library完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考