在开发打印扫描类系统时，经常会遇到用户输入格式不对、设备参数缺失等问题。比如用户上传一个不支持的文件类型，或者设置的打印份数是负数，这时候系统要是不做拦截，轻则报错卡顿，重则导致设备异常。所以参数校验绕不开，但关键问题是：它到底该放在哪一层处理？
常见的分层结构
大多数打印扫描服务都采用分层架构，比如前端界面、API 接口层、业务逻辑层、设备驱动层。每一层都有自己的职责，而参数校验如果放错位置，后期维护起来特别头疼。
前端做校验：第一道防线
用户在网页上填写打印页码、份数、纸张尺寸时，前端可以实时判断输入是否合法。比如输入“abc”作为份数，页面立刻提示“请输入有效数字”。这种反馈快，用户体验好，属于友好的第一道防线。
但它不可靠。用户可能绕过页面直接调用接口，或者用脚本批量提交请求。所以前端校验只能防误操作，不能当真。
API 层校验：守门员角色
真正该做基础校验的地方是 API 接口层。所有外部请求进来，先检查必填字段有没有，数据类型对不对，范围合不合理。比如扫描分辨率不能低于 72 或高于 1200，这类规则在这里拦下最合理。
if (!req.body.pages || req.body.copies < 1 || req.body.copies > 99) {\n return res.status(400).json({ error: '参数无效' });\n}这一层校验能防止非法数据进入系统核心，也减轻后续处理压力。很多打印网关服务就是在这里统一过滤请求。
业务逻辑层：深入规则判断
有些校验和具体业务强相关。比如某款老式打印机不支持双面彩色打印，这个限制不能写在前端或通用接口里，而要在业务逻辑中判断当前设备能力后再决定是否允许提交任务。
再比如，某个扫描配置组合会导致输出文件过大，超过系统限制，这种复合型规则也只能在业务层处理。
设备驱动层：最后的安全底牌
到了和硬件打交道的层面，参数必须严格匹配设备规格。驱动程序会再次确认传入的DPI、纸张类型、输出格式是否被支持。即使上层漏了，这里也能兜住，避免发送错误指令导致卡纸或固件崩溃。
但这不意味着可以把校验全推到最底层。那样问题发现得晚，日志难排查，用户收到的错误信息也不清晰。
实际场景建议
拿公司内部的打印审批系统举例：员工提交打印任务，前端检查格式和数量；API 层验证用户权限和基础参数；业务层判断是否符合部门配额；驱动层确保指令兼容目标打印机。每层各司其职，出问题能快速定位。
参数校验不是非此即彼的选择，而是分层设防。前端提升体验，API 拦截非法输入，业务处理复杂规则，底层保障设备安全。哪一层都不能少，但重点要放在 API 和业务层。