URLEncoder仅用于URL参数值（如key=value中的value）编码，不可用于完整URL或路径段；必须指定"UTF-8"编码，空格默认转为+而非%20，且其规则与RFC 3986不同。
URLEncoder 是专给 URL 参数值编码的，不是给整个 URL 或路径用的
它只负责把 key=value 里那个 value 部分（比如 "张三&李四"）转成服务器能安全接收的格式。别拿它去编码 https://example.com/path?x=1 这种完整 URL，也别用来处理路径段（如 /api/v1/用户），否则会把斜杠 /、问号 ? 这些关键分隔符也乱码掉。
- 正确场景：构造 GET 请求参数、拼接
application/x-www-form-urlencoded的 POST 表单体 - 错误场景：对
URI.getPath()结果调用URLEncoder.encode()、对完整 URL 字符串编码 - 路径编码应改用
java.net.URI构造器或手动按 RFC 3986 规则处理
必须显式指定 "UTF-8"，否则跨平台必出错
URLEncoder.encode(String) 已被标记为 @Deprecated，因为它依赖系统默认编码——Windows 可能是 GBK，Linux/macOS 默认是 UTF-8，同一段代码在不同机器上编码结果可能完全不同，导致中文参数在服务端解不出来。
- 永远用
URLEncoder.encode("中文", "UTF-8") - 如果传错编码名（如
"utf8"少个横线），会抛UnsupportedEncodingException - Spring 等框架的
@RequestParam虽自动解码，但前端若没按 UTF-8 编码，后端仍收不到原始字符
空格变 + 是特性，不是 bug；需要 %20 就自己替换
按照 application/x-www-form-urlencoded 规范，空格必须编码为 +，而不是 %20。这是历史兼容性要求，不是实现缺陷。但有些 HTTP 客户端或网关（尤其老设备）对 + 解析不一致，这时就得强制统一。
- 默认行为：
URLEncoder.encode("a b", "UTF-8")→"a+b" - 要
%20：后续加.replace("+", "%20") - 注意：
URLDecoder.decode()能同时识别+和%20，所以解码端通常不用改
别和 RFC 3986 百分号编码混用，URLEncoder 不等于通用 URL 编码
如果你在做路径编码（比如 /search?q=hello world 中的 hello world 是 query value，没问题；但 /user/张三 中的 张三 是 path segment，就不能用它），URLEncoder 会把 / 放过（不编码），而 RFC 3986 要求 path segment 里的非 unreserved 字符必须编码——包括 / 自身。
立即学习“Java免费学习笔记（深入）”；
-
URLEncoder规则：保留a-zA-Z0-9._*-，空格→+，其余 UTF-8 字节→%XX - RFC 3986 规则：仅保留
A-Za-z0-9-._~:/?#[\]@!$&'()*+,;=，其余一律%XX（且%必须大写） - 手写路径编码或用
java.net.URI更稳妥，别图省事硬套URLEncoder
+ 和 %20 的语义都和标准 HTTP 头部、现代 API 网关不完全对齐——用之前，先确认你编的是哪一段。 
