按维基百科的说法 token 并不是通行凭证而是用来获取凭证的东西(参考 google 的 refresh token 机制)
所以似乎说成凭证密钥 /凭证钥匙更为符合上下文？

不过感觉不好听，所以还是用 token 吧 :)狗头

我又想到了用铜丝焊 cpu 那个老表

@FaiChou 是这个意思，这方面暂时也想不到什么更好的办法
其实我觉得 url 的模式更好点，只需要劫持 url 请求就可以实现分流了
例如 tab1 的所有请求 url 都加上 trackcode=a3ef4de
然后 pac 就直接根据 code 分流很简单就实现了

不过也有缺点，可能某些严格匹配的地址会受影响(不过这种网址应该很少可以测测)

如果只通过 url 每个标签 url 后面加特征码判断 不用中间人理论上也是可以的 就是看着感觉有些奇怪 因为多了点东西

@FaiChou 例如，用插件给每个 tab 的流量附加一个 tab hash 的 header，中间人通过 header 判断转发不同代理就行了，实际上每一条连接都是可以单独设置代理的，只是 pac 的 api 只能判断 url 不能判断 header，不然都不需要中间人了

写过扩展插件，user data 的方式是可行的，只是占用资源多点
如果要实现同浏览器不同标签不同代理，按目前的 api 支持比较难，更可行的方式是中间人作为一级代理做流量分发、结合扩展可以实现，但是也需要开发下貌似没有现成代码

"这时会查出 a 表所有的记录"
加了 where 为什么会查出所有记录来，你用的盗版 mysql ？

按常规设计应该加一个 mapping(映射)表
但如果确定只有一条的话而且以后也不大可能更改的话按一楼说的要简单点效率也高点

cnblogs 真的是国内最丑的科技博客了，可以在 stylish 上美化，就可以分享给他人了

写入和输出都是高危操作，涉及到这种语句的地方都要进行路径正则严格匹配、mime 检查、后缀检查才放心

@cuiweiqiang 是开了，但是 ip 变动并不频繁 但是出问题的时候基本上 99%都会出这个问题，不出问题的时候就算用 wifi 也正常，如果是多拨导致的，我在外面有时用 4g 也有这问题就有点说不过去了
@revfan 多谢我试试看

刚刚试了下 我的百度云貌似又可以粘贴了 难道又去掉了

百度云服务还是挺不错的 不过客户端确实有点蛋疼
密码框这个也不是百度先搞的，其他很多网站都限制了密码粘贴，确实没明白他们怎么想的，可能觉得复制密码会被木马拦截很危险，但是不让复制很多小白可能会设置简单密码感觉更危险
锁定那个估计是为了推广手机 app 才加的新功能，可以在设置里关闭掉

@locoz 很多情形并不是开几台 vps 就能解决的，例如我有个业务每天需要 1w+ip，你需要开多少台才能满足需求？就算采用性价比最高的共享 IP 方案，每个 ip 每月成本也在 1 元左右，1w 个就是 1 万元，而且还无法保证每天的 ip 是不同的，而采用代理池方案，只需要微量成本(不到 100 元 /月)，我就可以每天获得 1w-10w 的有效 ip 请求，至于响应时间平均大概 2s 左右，但我通过提高并发让请求效率得到保证(目前最高大概只有 20/s 左右因为足够了)

@nozer 那你可以试试，我用这种方案基本不会遇到失败的情况，当然代理池后台也要加专门线程校验，剔除垃圾代理，按响应时间做排行

我之前给团队项目也写过一个代理池，但不是通俗意义上的隧道代理，而是 web 代理 ，支持加密传输，请求的时候同时开 N 个并发随机获取 ip 一起请求，谁先拿到数据就返回谁，然后可以自定义成功标识符，例如可以定义包含"code":1 才为成功，如果不包含则请求的并发会认为请求失败重试，这样使用起来效果很好，已顺利跑了半年多

multi dial

如楼上所说 实现太难
不过在抖音倒是看到过另类产品，不能减轻重量，但是背带和包之间加上缓冲器，行走时靠缓冲器抵消了一部分压力
原理是虽然重量是 20kg，但是由于人走路时会上下起伏，在加速度作用下背包实际给人造成的压力有可能会超过 20，而缓冲器能大幅度降低这种副作用
这个更有意义

确实挂了 不能访问