能否用&替代?作为查询参数起始符？非标准写法为何可行？

生效原因 #

• 服务器端解析逻辑兼容：多数后端框架或自定义的请求解析代码，不会严格校验查询参数的起始标识。它们通常会直接对URL中?之后的内容按&拆分，但如果URL里没有?，部分解析逻辑会把路径末尾后的&也当作参数分隔符，将&后面的内容识别为参数项。比如你给出的示例https://example.com/something&m，服务器会把&m解析成参数，完成追踪逻辑。
• 浏览器无主动拦截：浏览器在发送HTTP请求时，会原样传递整个URL，不会因为不符合标准格式就拒绝发送，只要后端能解析，就能正常生效。
• 自定义追踪系统适配：你们的用户来源分析系统本身就是按照这个非标准规则开发的，自然能识别这种&起始的参数，完成数据统计。

可行性分析 #

这种写法短期能满足需求，但存在不少潜在风险，不建议长期使用：

• 兼容性不稳定：不同后端框架、CDN、代理服务器的解析逻辑差异很大，比如一些严格遵循RFC标准的服务会直接忽略?之前的&内容，导致追踪参数失效，出现统计数据缺失的情况。
• 易引发URL歧义：如果业务路径中不小心包含&字符（虽然规范不推荐，但实际场景可能出现），会被误解析成参数分隔符，导致服务器识别错误的路径或参数，引发业务异常。
• 违反URL标准规范：标准URL的查询参数必须以?起始、&分隔，这种自定义写法偏离规范，后续如果更换服务架构、升级后端框架，大概率会出现兼容性问题，排查和修复成本很高。
• 安全工具拦截风险：部分浏览器隐私扩展、安全检测工具可能会将这种非标准URL判定为异常请求，进行拦截或修改，导致追踪数据丢失。

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