当通过 url 查询参数传递字符串列表时，若列表元素本身包含逗号（如公司名 “anhui jantene hone textiles co., ltd.”），默认以逗号分隔会导致解析错误——一个合法元素被错误拆分为多个，破坏列表语义。根本解法是避免在 query string 中直接序列化复杂列表，改用 post 请求体传输 json 格式数据。
在 Web 开发中，将客户端筛选条件（如多选标签、批量 ID 或企业名称列表）传递至后端时，开发者常倾向使用 GET 请求并拼接查询参数，例如：
GET /api/search?params=[First_value],[Anhui Jantene Hone Textiles Co., Ltd.],[Third_Value]
这种看似直观的方式存在严重缺陷：HTTP 查询字符串本身不定义列表结构，服务端（如 Spring Boot 的 @RequestParam List
✅ 正确做法：改用 POST + JSON 请求体
将列表数据封装为标准 JSON 数组，通过请求体（Request Body）传输，完全规避 URL 编码与分隔符歧义问题：
POST /api/search HTTP/1.1 Content-Type: application/json
["First_value", "Anhui Jantene Hone Textiles Co., Ltd.", "Third_Value"]
后端（以 Spring Boot 为例）可直接接收为类型安全的列表：
@PostMapping("/api/search")
public ResponseEntity<?> handleSearch(@RequestBody List<String> params) {
// params 精确对应原始数组，无分割风险
System.out.println("Received " + params.size() + " items"); // 输出: Received 3 items
return ResponseEntity.ok().build();
}⚠️ 补充说明与注意事项：
立即学习“Java免费学习笔记（深入）”；
- 不要尝试 URL 编码逗号来“修复”：即使对 , 手动编码为 %2C，前端框架（如 Axios）或后端解析器仍可能在预处理阶段解码并按逗号分割，可靠性极低；
- 避免自定义分隔符（如 | 或 ;）：虽可行，但需前后端严格约定、额外转义逻辑，违背 REST 规范且增加维护成本；
- GET 请求有长度限制：长列表易触发 URL 截断（尤其 IE 限制约 2048 字符），而 POST 请求体无此硬性约束；
- 若必须使用 GET（如 SEO 或缓存需求），应改用多个同名参数：?params=First_value¶ms=Anhui%20Jantene%20Hone%20Textiles%20Co.%2C%20Ltd.¶ms=Third_Value，此时 Spring Boot 可正确聚合为 List
，但需确保前端正确编码特殊字符（特别是逗号和空格）。
综上，面对含标点符号的字符串列表传输，JSON over POST 是最健壮、可扩展、符合现代 API 设计规范的方案。它消除了序列化歧义，保障数据完整性，并为未来支持嵌套对象、类型字段等复杂结构预留空间。
