分享一个关于PAC脚本的问题

[rankjie]

刚刚发现PandaFan的服务在Wi-Fi下出现了故障，3G下则没有问题，仔细排查了一下发现问题只可能出在PAC脚本上。

PandaFan的PAC是白名单机制，即：记录在PAC的白名单list中的域名会直接连接，未在白名单中找到的域名和直接的IP访问会通过代理来访问。
白名单是会自动学习的，详见： http://v2ex.com/t/64373

首先尝试打开Tweetbot for Mac，发现无法刷出TL新内容，虽然下拉出现的更新条出显示的是Streaming...

查看 chrome://net-internals/#proxy 发现应用PAC的情况下，Effective settings居然是direct connection。检查了下当前的白名单域名数，发现已经增长到了9000多个，猜测是否是域名太多了超出浏览器限制，于是就把之前一份只有5000多域名的白名单备份替换了上去，问题解决了，浏览器重新应用了PAC脚本，Tweetbot等应用，包括系统的通知中心也重新开始正常工作。

这个问题具体产生的原因还是不清楚，但可以排除是PAC文件过大的原因（9000多域名的PAC文件大小为131KB）

另外，PandaFan的PAC执行的具体流程是：
先将访问的域名和一份很短的黑名单进行匹配，如果匹配成功会直接通过代理访问，没有在黑名单离匹配到的才会再进行白名单匹配。

这样的设计能解决一个问题：当自动学习生成的白名单中收录有无法访问的域名时，只要黑名单中收录有该域名，那么就能正确的通过代理去访问。
而现在发现的情况是系统根本没有去应用这个PAC，直接统统进行了直接访问，非常奇怪

大家有什么猜想吗？
或者有哪位老师了解的比较多，可以分享一下背后的原理？

[XiegongJi]

貌似某些浏览器对PAC脚本中的数组元素个数有限制。
不过你可以多定义几个数组或对同一数组多次赋值，从而突破这个限制:
auto_list=[a,b,c];//元素个数不要超过MAX_SIZE
//some code ...
auto_list=[d,e,f];//元素个数不要超过MAX_SIZE
//some code ...
auto_list=[g,h,i];//元素个数不要超过MAX_SIZE
//some code ...