产品搜索API设计：VendorId与LocationId设为数组是否符合后端最佳实践？

直接给结论：这么做完全没问题，甚至是提前规避耦合、预留扩展性的最佳实践之一，原因很简单：

• 彻底解耦前后端：当前前端是单选下拉，但后端接口设计没必要绑定前端的交互形式。改成数组后，哪怕后续前端改成多选、批量导入筛选条件，后端都不用改接口，省掉后续重构的麻烦
• 实现成本极低：正如你提到的，只需要把SQL里的=换成IN，请求类里的字段从单个Integer改成集合/数组就行，几乎没有额外开发成本
• 适配更多场景：除了前端的多选择需求，后续如果有内部系统批量查询、第三方调用批量筛选的场景，这个接口直接就能支持，不用再单独开发新接口

修改后的请求类代码（注意命名统一） #

原代码里providerId和SQL里的vendorId命名不一致，建议统一成vendorIds避免混淆：

public class GetProductRequest {
    private String productSearchString;
    // 改为List<Integer>支持多ID传入
    private List<Integer> locationIds;
    private List<Integer> vendorIds;

    private String sortField = "ProductName,desc";
    private int pageNumber = 0;
    private int pageSize = 10;
}

额外注意事项 #

1. 处理空集合的边界情况：如果前端没传这两个参数（或者传了空数组），SQL里的IN ()会直接报错，需要在业务逻辑里判断：
   • 如果locationIds为空，就去掉productContract.LocationId in (@LocationIds)这个条件
   • 如果vendorIds为空，就去掉productContract.vendorId in (@vendorIds)这个条件
2. 保持参数化查询：你当前用@vendorIds这种参数化的方式是对的，绝对不要直接把ID拼接成字符串，避免SQL注入风险

内容的提问来源于stack exchange，提问作者mattsmith5