java无法强制前端传参，但可通过service层定义语义化受检异常（如missingorderidexception）、方法签名throws声明及controller显式处理，将核心参数缺失转化为编译期强制校验，倒逼前后端重视接口契约。
Java 本身无法直接“强制前端必须传递参数”，因为前端（如浏览器、App）和后端是分离的，参数是否传递取决于 HTTP 请求本身。但你可以利用受检异常 + 接口契约设计 + 编译期约束，在后端关键路径上强制业务逻辑层校验核心参数是否存在、合法，并让缺失或非法参数立刻触发编译可感知、调用必处理的失败信号——从而倒逼接口设计者、前后端联调者、甚至 Swagger 文档生成工具重视这些参数。
这不是控制前端行为，而是让“漏传核心参数”这件事，在后端代码层面变成一个无法绕过、无法忽略、必须显式响应的问题。
受检异常不能直接约束 HTTP 请求，但能约束方法调用契约
Java 的受检异常（Exception 子类，非 RuntimeException）只对Java 方法调用链生效。它不拦截 HTTP 请求，但可以约束 Controller → Service → Domain 这一内部调用链。只要你在 Service 层定义了“缺核心参数就抛受检异常”，那么：
- Controller 必须
try-catch它，或throws向上传递； - 如果 Controller 没做任何处理，编译直接失败；
- 开发者无法假装“参数可能为空”，必须面对“如果没传，这里就会炸”。
这就把前端是否传参的责任边界，从模糊的文档约定，推进到清晰的编译强制。
在 Service 层定义精准的受检异常并绑定参数校验
不要写泛化的 MissingParameterException，而要为每个关键参数场景定义独立异常，命名体现语义和可操作性：
-
MissingOrderIdException：订单 ID 是后续库存锁定、支付路由的必要输入 -
UnspecifiedPaymentMethodException：支付方式未选，无法进入风控/渠道路由逻辑 -
EmptyCustomerPhoneException：手机号为空，合规校验与短信通知无法进行
示例：
public class MissingOrderIdException extends Exception {
public MissingOrderIdException(String message) {
super(message);
}
}
然后在核心业务方法中显式声明：
public Order confirmOrder(OrderConfirmRequest req)
throws MissingOrderIdException, UnspecifiedPaymentMethodException {
if (req.getOrderId() == null || req.getOrderId().trim().isEmpty()) {
throw new MissingOrderIdException("订单ID为必填项，不可为空");
}
if (req.getPaymentMethod() == null) {
throw new UnspecifiedPaymentMethodException("支付方式未指定");
}
// ... 继续执行
}
⚠️ 注意：这个方法签名里的
throws是关键。它让所有调用confirmOrder()的地方，都逃不过编译器检查。
Controller 层必须显式应对，自然暴露参数依赖
Controller 不再能“默默吞掉”或忽略参数缺失。它必须选择：
-
就地捕获并转成友好的 HTTP 响应（推荐）：
@PostMapping("/orders/confirm") public ResponseEntity> confirm(@RequestBody OrderConfirmRequest req) { try { Order order = orderService.confirmOrder(req); return ResponseEntity.ok(order); } catch (MissingOrderIdException e) { return ResponseEntity.badRequest() .body(Map.of("error", "MISSING_ORDER_ID", "message", e.getMessage())); } catch (UnspecifiedPaymentMethodException e) { return ResponseEntity.badRequest() .body(Map.of("error", "MISSING_PAYMENT_METHOD", "message", e.getMessage())); } } 或继续向上
throws（不推荐用于 Web 层，但可用于内部 RPC 接口）
这样做的效果是：
✅ 所有调用 confirmOrder() 的代码，都必须直面“参数缺失会怎样”；
✅ Swagger/OpenAPI 生成时，可通过 @ApiResponses 显式标注这些异常对应的 400 错误码和字段说明；
✅ 新人看代码，一眼就知道 confirmOrder() 依赖哪些参数 —— 不靠注释，靠编译错误提醒。
配合 @NotNull 和请求校验进一步加固（非替代，是协同）
虽然受检异常管的是“业务逻辑入口”，但你还可以叠加：
-
@NotNull/@NotBlank等 Bean Validation 注解，在@RequestBody入参上做前置拦截：public record OrderConfirmRequest( @NotNull(message = "订单ID不能为空") String orderId, @NotNull(message = "支付方式不能为空") PaymentMethod paymentMethod ) {}配合
@Valid，可在 Controller 入口统一返回 400，避免进入 Service。
但这只是补充：Validation 拦截的是“空值”，而受检异常可以表达更复杂的业务规则（如“订单ID格式合法但不在待确认状态”），且它的 throws 声明是跨模块、可被 IDE 和 CI 工具识别的契约信号。
本质上，@NotNull 是“语法检查”，受检异常是“语义契约”。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
