必须双重编码Cookie值：PHP侧setcookie('k', urlencode('v'))使浏览器发送ab%2Bcd，PHP解码得ab+cd，Java读原始值ab%2Bcd后需URLDecoder.decode()还原，双方一致；或改用自定义Header彻底规避。
要让PHP8.3和Java19在Web请求中对同一Cookie值解析一致，必须处理PHP自动URL解码与Java原样保留之间的差异，否则test1=ab%2Bcd在PHP中变成ab+cd、在Java中仍是ab%2Bcd，导致身份校验失败或会话中断。
理解底层行为差异
PHP8.3默认对Cookie值执行一次urldecode()，这是由SAPI层在php_default_treat_data()中硬编码实现的，无论是否启用variables_order或使用setrawcookie()都无法绕过该解码逻辑；Java19（如Spring Boot 3.2+或原生Servlet）则完全不干预Cookie原始字节流，request.getCookies()返回的Cookie.getValue()就是HTTP头里收到的原始字符串，+号不转空格、%2B不还原为+。
这一步差异不是配置问题，是语言运行时设计决定：PHP把Cookie当作“用户输入变量”统一预处理，Java把它当作“原始HTTP字段”交由开发者自行解析。
PHP8.3侧规避自动解码
方法一：用setrawcookie()发送，但接收端仍被解码——此法无效，setrawcookie()只影响发送时不编码，不影响接收时的强制解码。
立即学习“PHP免费学习笔记（深入）”；
方法二：双重编码。在PHP设Cookie前手动urlencode()一次，例如setcookie('test1', urlencode('ab+cd'))，这样浏览器收到的是test1=ab%2Bcd，PHP解码后变回ab+cd，与Java读到的原始值一致。但注意：若Java端也做了一次URLDecoder.decode()，就会过度解码，需双方约定仅PHP侧双编、Java侧不 decode。
方法三：改用Header传值。放弃Cookie:头，改用自定义Header如X-Auth-Token，PHP用header('X-Auth-Token: ab%2Bcd')，Java用request.getHeader("X-Auth-Token")直接获取，彻底避开Cookie解析链。此法需前端AJAX显式携带该Header，且无法利用浏览器自动续发机制。
Java19侧主动适配PHP
第一步：识别PHP风格Cookie。检查Cookie对象的getValue()是否含空格或已解码的+号——若test2=ab+cd中+未被Java转为空格，说明未被解码；若已为空格，则Java环境可能启用了额外过滤器。
第二步：按PHP逻辑模拟解码。对每个Cookie值调用URLDecoder.decode(cookie.getValue(), "UTF-8")，但【必须跳过已含%xx序列的值】，否则ab%2Bcd会被解成ab+cd再解成ab cd。判断依据：若值中存在%[0-9A-Fa-f]{2}且无空格，大概率是PHP双编后的结果，此时不应再decode。
第三步：统一归一化。将所有Cookie值先URLEncoder.encode()再URLDecoder.decode()，可消除+号歧义，但会丢失原始编码意图，仅适用于纯ASCII场景。
跨语言调试验证步骤
① 用curl构造原始请求：curl -H "Cookie: test1=ab%2Bcd; test2=ab+cd" http://localhost:8080/，分别在PHP8.3和Java19服务端打印原始Header和解析后值。
② 在PHP中用getallheaders()['Cookie']获取原始Header字符串，确认是否被NGINX/Apache提前修改——某些反向代理会重写Cookie头，导致PHP收不到原始值。
③ 在Java中用request.getReader().readLine()捕获完整HTTP请求头（需配置容器允许），比getCookies()更底层，可验证是否在Servlet解析前已被篡改。
④ 对比两端日志时间戳和请求ID，确保测试的是同一请求，避免缓存或负载均衡分发到不同实例造成误判。
在Java19中调用request.getCookies()前插入Thread.sleep(1)无意义，因Cookie解析发生在请求初始化阶段，非运行时动态行为。
