前端参数类型验证核心是测“实际类型”而非“外观”，单元测试中应优先用toThrowError匹配错误构造函数，异步场景用rejects，手动catch可灵活校验错误细节，参数类型用typeof、Array.isArray等精准判断。
前端开发中验证参数类型，核心不是测“它看起来像什么”，而是测“它实际是什么”——尤其在单元测试里，类型断言必须稳定、可重现、不依赖 message 文本或运行环境。
用 toThrowError 精准匹配错误构造函数
当函数对非法参数抛出特定错误（如 TypeError、RangeError 或自定义错误类），别用 toThrow('TypeError') 去匹配错误消息字符串——那容易因拼写、空格、国际化而失败。
- ✅ 正确：校验构造函数本身，大小写敏感但稳定
expect(() => parseJSON('{')).toThrowError(SyntaxError); - ✅ 支持字符串类名（推荐用于简单场景）
expect(() => divide(10, 'zero')).toThrowError('TypeError'); - ❌ 错误：只写
toThrow('TypeError')—— 这是在断言 message，不是类型
异步函数要换用 rejects
如果被测函数返回 Promise 并在参数错误时 reject 一个错误实例（比如 API 调用、fetch 封装），不能用 toThrowError，因为它只处理同步抛错。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- ✅ 正确：用
rejects.toThrowError或rejects.toBeInstanceOfawait expect(fetchUser(null)).rejects.toThrowError(TypeError);await expect(validateId('')).rejects.toBeInstanceOf(ValidationError); - ❌ 错误：
expect(() => fetchUser(null)).toThrowError(...)—— 函数立刻返回 Promise，不会同步抛错
手动捕获 + toBeInstanceOf 更灵活
当你需要同时验证错误类型、message、code 或堆栈等字段，或者使用 Chai、node:assert 等不支持 toThrowError 的断言库时，用 try-catch 是通用解法。
立即学习“Java免费学习笔记（深入）”；
- 先执行，再捕获错误实例
let error;<br>try { unsafeProcess({ id: null }); } catch (e) { error = e; } - 必须加兜底判断，防止没抛错导致后续断言报 undefined 错误
expect(error).toBeDefined();<br>expect(error).toBeInstanceOf(TypeError);<br>expect(error.message).toContain('id must be a string');
参数本身类型验证：结合 typeof / instanceof / toString.call
单元测试中常需确认传入参数是否符合预期类型（比如函数只接受数组，或必须是 Date 实例）。这时直接在测试用例里做判断更清晰：
- 基本类型优先用
typeof：expect(typeof input).toBe('string');expect(typeof value).toBe('number'); - 引用类型避免
typeof（它对数组/日期都返回"object"），改用：
–Array.isArray(input)判断数组
–input instanceof Date判断日期（注意跨 iframe 失效）
–Object.prototype.toString.call(input) === '[object RegExp]'判断正则等特殊对象
