parse_qs 返回列表是因为支持重复键名，属设计行为；需先解码再解析，用unquote_plus处理加号；空键需校验，空值语义需keep_blank_values=true区分。
parse_qs 解析出来的值为什么全是列表？
因为 URL 查询参数允许重复键名，比如 ?tag=python&tag=web&user=id123，parse_qs 默认按“多值优先”设计，把每个键映射为 list，哪怕只出现一次也会包成 ['value']。这不是 bug，是明确的行为契约。
常见错误现象：直接取 result['user'][0] 却没检查 key 是否存在，或误以为能用 result['user'] 当字符串用而触发 KeyError 或 TypeError。
- 若确认参数不会重复（如标准 REST API），可用
parse_qsl替代，返回[(key, value)]列表，再转成字典：dict(parse_qsl(query_string)) - 想保留单值语义又不想写
[0]，可后处理：{k: v[0] for k, v in parse_qs(query).items()}，但注意这会静默丢弃重复项 -
parse_qs的keep_blank_values=False（默认）会把?name=&age=25中的name键过滤掉；设为True才得到{'name': ['']}
中文、空格、加号这些字符解析不对怎么办？
parse_qs 本身不负责解码，它依赖输入已是 URL 解码后的字符串。如果你传入原始 query 字符串（如 'q=%E4%BD%A0%E5%A5%BD&sort=+time'），必须先用 unquote 处理。
典型错误：直接对 request.url 全量调用 parse_qs，却忘了切出 query 部分并解码。
- 正确链式写法：
from urllib.parse import parse_qs, unquote; parse_qs(unquote(urlparse(url).query)) - 加号
+在传统表单编码中代表空格，但unquote不处理它；要用unquote_plus才行 - 如果 query 来自
request.GET（Django）或request.args（Flask），框架通常已帮你解码，此时可直接parse_qs，无需再unquote
和 parse_qsl 相比，什么时候非用 parse_qs 不可？
当你需要区分“参数未提供”和“参数值为空”时，parse_qs 是唯一选择——它能通过 keep_blank_values=True 显式保留空值，且天然支持多值语义。
使用场景举例：筛选接口支持 ?category=&category=book&category=video，其中空 category 表示“不限”，不能和缺失 category 混淆。
-
parse_qsl('a=&b=1')→[('a', ''), ('b', '1')]，但无法表达“a 根本没传” -
parse_qs('a=&b=1', keep_blank_values=True)→{'a': [''], 'b': ['1']} -
parse_qs('b=1', keep_blank_values=True)→{'b': ['1']}，a键根本不存在，可安全用in判断 - 性能上，
parse_qs略慢于parse_qsl（因构建 dict + list），但差异在微秒级，除非高频解析百万级 query，否则不用纠结
遇到 malformed URL 会怎样？
parse_qs 对格式极其宽容：缺失等号、多余 &、乱序 =、甚至无 key 的 &&=val 都不会报错，而是尽力提取“看起来像键值对”的部分。这意味着它几乎从不抛异常，但也意味着坏数据会静默通过。
典型问题：前端拼接 query 时漏了 key，生成 ?=abc&type=public，parse_qs 会返回 {'': ['abc'], 'type': ['public']}——空字符串键容易引发后续逻辑崩溃。
- 建议在业务层加校验：
if '' in result: raise ValueError("Empty key in query string") - 若需严格模式，别用
parse_qs，改用正则预清洗，或借助urllib.parse.urlencode反向验证（但成本高） - Python 3.9+ 的
urllib.parse没有内置 strict mode，别指望靠升级版本解决校验问题
KeyError: '' 或乱码字符串，得倒着查三遍才定位到 unquote_plus 忘写了。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
