@zhangsimon emmmm...你问上世纪出生的我 我也回答不了 这就好像 70 岁的大爷懵逼的看着我们刷微博抖音朋友圈一样 不得要领 只知道他们玩的非常 happy

如果你能彻底理解 90 00 后在玩什么
我觉得你应该是赚钱赚到没空来发这篇帖子的

之前写过 c 版的 aes 虽然加了 iv 但是我不想记录这个 于是每次都是随机 iv 加密 空 iv 解密 解密后抛弃第一个块(因为第一个块无法解密) 后面的就是原始数据

感觉你这问题和这有些关系 你可以使用相同的 iv(例如全 0 值) 打印解密后的原始数据看看一不一样

加 google 的选择验证码 连人都通不过 100% :)

文章存 oss 并不需要多少成本 1 个月可能 2 块钱不到
wp 确实不好优化 可以考虑静态化插件

简书手机版跟赌博网站流氓程度是一样的

@CEBBCAT 恕我直言 锅是什么鬼，你确定不是祸

用的 go 调用 ff 处理 感觉转码目前来说没有什么问题 处理的时候注意编码格式 色彩格式 采样率 音视轨时长就好了

按维基百科的说法 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 上美化，就可以分享给他人了