函数入口参数校验核心是“早发现、早报错、不执行后续逻辑”，需用typeof严格判断类型、区分null/undefined、防NaN，配置对象用解构默认值防御，按参数数量校验，复杂规则抽离为自定义校验函数并抛出具体错误。
在函数入口做参数校验，核心目标是“早发现、早报错、不执行后续逻辑”。这不是锦上添花，而是防御性编程的第一道闸门——只要参数不对，函数立刻终止，避免错误蔓延或产生副作用。
用 typeof + 严格判断拦截基础类型
这是最直接、开销最小的拦截方式。重点不是“能识别什么”，而是“明确拒绝什么”。
- 检查是否为期望类型：比如
typeof name !== 'string'就抛错，不依赖隐式转换 - 区分
null和undefined：两者typeof都返回'object'，需单独判断value === null或value === undefined - 对数字要额外防
NaN：用Number.isNaN(value)，而不是value !== value这种黑魔法
用解构默认值 + 外层空对象防御拦截配置参数
当函数接收一个配置对象时，入口校验的关键是“不让解构本身崩溃”。
- 先写
function api({ url, timeout = 5000 } = {})：等号右边的{}拦住undefined或null传入导致的解构报错 - 再逐个校验解构出的字段：比如
if (!url || typeof url !== 'string')，而不是把所有逻辑塞进默认值表达式里 - 嵌套对象也同理：
{ data: { code = 0 } = {} } = opts，外层= {}和内层= {}缺一不可
用 arguments.length 或 rest 参数拦截数量和必填项
参数个数不对，往往意味着调用方理解有误，应第一时间暴露问题。
立即学习“Java免费学习笔记（深入）”；
- 固定参数函数：用
arguments.length !== 3明确报错，比让后续逻辑因缺参而崩更友好 - 支持可选参数时，用 rest 参数（
...rest）配合长度判断，例如要求至少前两个参数必须存在 - 避免只靠默认值兜底：默认值解决的是“没传”，不是“传错了”；
fn(undefined, 123)仍会触发默认值，但可能违背业务意图
用自定义校验函数统一拦截复杂规则
当校验逻辑涉及多个参数联动、范围约束或业务含义时，抽离成独立函数能让入口清晰且可复用。
- 例如：
const { start, end } = validateRange({ start, end })，校验函数内部处理大小关系、边界修正等 - 校验函数应返回修正后的值，或直接 throw 错误，不建议返回布尔值再在外层 if 判断——那又回到了分散校验的老路
- 错误信息要具体：
throw new Error('start 必须小于 end，当前 start=100, end=50')，方便调试定位
