1. 三方合作会员（京东、淘宝，联合会员等等）；
2. 优惠券或者特殊活动渠道；
3. apple 退款套的会员；（或者其他方式退款套的，比如信用卡，虚假付费）
4. 喜钱（这类八九折话费的比较多）；
5. 过期电话卡或者一些其他快过期的付费方式，卡出来的。

idm 吧，会自动添加网站的 cookie 下载，实在不行就 python 跑吧，很多的大文件下载都有问题，有的不支持多文件下载，有的不支持多线程，有的有连接时间限制，这种很难判断到底是哪儿出了问题。

你把代理规则关了，弄成全局看还有没有这个问题，我上次发现很多程序都有因为代理频繁发送请求的问题，有的程序会发送一些特殊请求包进行验证，如果你的代理中有相关的广告规则把他的请求 block 了，他就会不停发送，不停发送……我最近用 v2 的时候也出现这种情况，具体应用是字节的豆包 ai 不停发送请求。如果还有这个问题，就可以考虑安全方面的问题了

国内没有几个平台用于记录这种吧，建议是自己搭建个静态博客，或者放 vercel 部署

可以使用自定义的编码方式来处理这个问题。思路如下：
对于 param 中的数据，将其键值对按照一定规则拼接成字符串，而不是直接使用 JSON 序列化。
例如，如果 param 是 {"key1": "value1", "key2": "value2"}，可以将其拼接为 key1=value1&key2=value2 的形式。
在前端和后端约定好这个编码规则。
前端在发送请求时，按照这个规则将 param 中的数据拼接成字符串，然后将整个渲染参数对象构建成 URL 的查询参数形式。
后端接收到请求后，先解析出 code 和 type ，然后根据约定的规则将 param 部分的字符串再解析回键值对的形式。
这样做的好处有：
不需要依赖复杂的第三方库或者特殊的设置（如 ensure_ascii=False ），并且完全符合只能使用 GET 请求且参数不能嵌套的要求。
避免了 JSON 序列化可能带来的转义问题，同时也没有增加过多的复杂操作（相比于先序列化再 base64 编码的方式）。
输出的结果相对简洁且人类可读程度较高，只要了解规则，在调试等情况下也比较容易理解。

你是上班又不是个人开发，你该考虑是承担责任和自己摸鱼的进度，这种你最多随口一提，老板用采用就用，不用就按着他的来，如果建议的话，采用了你的原生，以后出了 bug 或者漏洞，业务因为技术出了问题，有可能会甩锅给你，说是你推荐的技术有问题🙄

2024-08-11 更：有人问为啥要用搜狗（不用 rime 、xxx ），谁不知道搜狗的不良行为，但是就搜狗联想和云计算方面，搜狗一直是音码的 top1 ，这是很难撼动的，毕竟有大基数的人为他的联想做贡献（收集用户数据），其次是上次那个占用率高的问题，一方面是搜狗云计算的锅，有时候在更新之后就会出现。目前换成了搜狗输入法智慧版，对于广告和占用问题有较大改善，如果你是搜狗用户，推荐使用。