目前参与的项目中有个弹窗音乐播放器，使用url传参（模拟get方法）实现无刷新为播放器（弹窗）添加歌曲列表的功能。偶尔会遇到歌曲列表被截断的情况。仔细研究后发现只有在首次弹窗时发生问题，如果传参时播放器窗口已打开，则无此问题。
刚开始以为是脚本加载或执行过程中依赖关系处理不当导致此问题，而窗口已打开由于加载缓存文件较快不存在网速影响。直到今天安插debug脚本结合调试工具才发现真正的问题在于通过url传递的参数超长部分被截断了，诡异之处在于：播放同样的歌曲列表，按理说传递的参数包括参数长度都是一样的，如果是浏览器限制导致问题，给同样的参数应该产生相同的结果才对，而实际操作中却只在首次播放（弹窗口）时出现参数被截断的问题。
唯一可能导致问题的差异变量是目标窗口（以window.name标识）的存在情况，通过window.open打开一个指定name参数的窗口，如果该窗口不存在，则传递的url参数（字符串）长度超过2083部分被舍弃；若目标窗口存在，则url参数长度超过4113部分被舍弃。
截图为证：
最后经证实，仅在IE下存在此差异，FF下首次和之后弹窗传参的长度并无差异。
IE最大URL长度2083的限制官方已有给出 （http://support.microsoft.com/kb/208427）而window.open可以让IE获取到长度达4113的url却是这次troubleshooting的意外收获。
最初认为是脚本加载导致问题的判断显然是错误的，错误的判断基于测试人员的描述和自身经验形成的思维定势；到后来亲手测试不同情况，找到产生问题的差异变量为线索；直至最后按图索骥，编写专门的调试函数，找到问题产生的根源并通过对比和量化来证实结论。
测试环境：ie8浏览器。
启示：
永远别试图摸透（老版本？）IE的怪癖行为；
不要被问题的诡异表象所迷惑，要弄清问题产生根源还得靠回归代码和调试工具。
