update20151202：
感谢大家的关注和回答，目前我从各种方式了解到的防御方法，整理如下：
php直接输出html的，可以采用以下的方法进行过滤：
1.htmlspecialchars函数2.htmlentities函数3.htmlpurifier.auto.php插件4.removexss函数（百度可以查到）

php输出到js代码中，或者开发json api的，则需要前端在js中进行过滤：
1.尽量使用innertext(ie)和textcontent(firefox),也就是jquery的text()来输出文本内容2.必须要用innerhtml等等函数，则需要做类似php的htmlspecialchars的过滤（参照@eechen的答案）

其它的通用的补充性防御手段
1.在输出html时，加上content security policy的http header（作用：可以防止页面被xss攻击时，嵌入第三方的脚本文件等）（缺陷：ie或低版本的浏览器可能不支持）2.在设置cookie时，加上httponly参数（作用：可以防止页面被xss攻击时，cookie信息被盗取，可兼容至ie6）（缺陷：网站本身的js代码也无法操作cookie，而且作用有限，只能保证cookie的安全）3.在开发api时，检验请求的referer参数（作用：可以在一定程度上防止csrf攻击）（缺陷：ie或低版本的浏览器中，referer参数可以被伪造）

大概就是这些了，大家还有什么别的思路，欢迎补充！
——————————————————————————————————————————————————
原问题如下：
1.php如何完美（或者尽可能完美地）防御xss攻击（比htmlspecialchars更完善的）？
2.我在想是不是防御xss最好在前端做（毕竟js在前端解析字符串都有坑啊）？
3.有木有什么解决方案或者思路啊，什么都行？
最近都在研究xss防御的问题。
毕竟，比如用户注册的api，可能被hacker利用，强行提交了这样的用户名。
然后web前端怎么都要有显示用户名的地方吧。。。
于是。。。boom。。。
直入重点:
我看到很多应对xss的防御方案都是php的htmlentities函数或者htmlspecialchars。
随意百度了下，貌似thinkphp3.x默认就是用的htmlspecialchars。
比如：$str = htmlspecialchars($str, ent_quotes);//替换掉&'这5个字符
但是，只替换掉那几个字符真的够吗？
然后我发现了这个文章：
http://tieba.baidu.com/p/3003719171
使用\u003c\u003e在js字符串中会被解释成的特性进行xss攻击。。。
卧槽。。。
然后我想到了js里的eval等等函数简直是无底洞。。。
然后我发现了这个文章：
http://www.2cto.com/article/201310/251830.html
使用各种编码，各种手段执行js，简直丧心病狂。
比如：
啊！cao。
我开始怀疑整个世界了。。。
所以，
我的问题是：
1.php如何完美（或者尽可能完美地）防御xss攻击（比htmlspecialchars更完善的）？
2.我在想是不是防御xss最好在前端做（毕竟js在前端解析字符串都有坑啊）？
3.有木有什么解决方案或者思路啊，什么都行？
update20151201：
能不要再复制粘贴答案，or迷信htmlspecialchars是无敌的了好嘛？
\u003cimg src=1 onerror=alert(/xss/)\u003e里的任何一个字符都是不会被htmlspecialchars处理的。
自己看图，对，就是你！
回复内容： update20151202：
感谢大家的关注和回答，目前我从各种方式了解到的防御方法，整理如下：
php直接输出html的，可以采用以下的方法进行过滤：
1.htmlspecialchars函数2.htmlentities函数3.htmlpurifier.auto.php插件4.removexss函数（百度可以查到）

php输出到js代码中，或者开发json api的，则需要前端在js中进行过滤：
1.尽量使用innertext(ie)和textcontent(firefox),也就是jquery的text()来输出文本内容2.必须要用innerhtml等等函数，则需要做类似php的htmlspecialchars的过滤（参照@eechen的答案）

其它的通用的补充性防御手段
1.在输出html时，加上content security policy的http header（作用：可以防止页面被xss攻击时，嵌入第三方的脚本文件等）（缺陷：ie或低版本的浏览器可能不支持）2.在设置cookie时，加上httponly参数（作用：可以防止页面被xss攻击时，cookie信息被盗取，可兼容至ie6）（缺陷：网站本身的js代码也无法操作cookie，而且作用有限，只能保证cookie的安全）3.在开发api时，检验请求的referer参数（作用：可以在一定程度上防止csrf攻击）（缺陷：ie或低版本的浏览器中，referer参数可以被伪造）

大概就是这些了，大家还有什么别的思路，欢迎补充！
——————————————————————————————————————————————————
原问题如下：
1.php如何完美（或者尽可能完美地）防御xss攻击（比htmlspecialchars更完善的）？
2.我在想是不是防御xss最好在前端做（毕竟js在前端解析字符串都有坑啊）？
3.有木有什么解决方案或者思路啊，什么都行？
最近都在研究xss防御的问题。
毕竟，比如用户注册的api，可能被hacker利用，强行提交了这样的用户名。
然后web前端怎么都要有显示用户名的地方吧。。。
于是。。。boom。。。
直入重点:
我看到很多应对xss的防御方案都是php的htmlentities函数或者htmlspecialchars。
随意百度了下，貌似thinkphp3.x默认就是用的htmlspecialchars。
比如：$str = htmlspecialchars($str, ent_quotes);//替换掉&'这5个字符
但是，只替换掉那几个字符真的够吗？
然后我发现了这个文章：
http://tieba.baidu.com/p/3003719171
使用\u003c\u003e在js字符串中会被解释成的特性进行xss攻击。。。
卧槽。。。
然后我想到了js里的eval等等函数简直是无底洞。。。
然后我发现了这个文章：
http://www.2cto.com/article/201310/251830.html
使用各种编码，各种手段执行js，简直丧心病狂。
比如：
啊！cao。
我开始怀疑整个世界了。。。
所以，
我的问题是：
1.php如何完美（或者尽可能完美地）防御xss攻击（比htmlspecialchars更完善的）？
2.我在想是不是防御xss最好在前端做（毕竟js在前端解析字符串都有坑啊）？
3.有木有什么解决方案或者思路啊，什么都行？
update20151201：
能不要再复制粘贴答案，or迷信htmlspecialchars是无敌的了好嘛？
\u003cimg src=1 onerror=alert(/xss/)\u003e里的任何一个字符都是不会被htmlspecialchars处理的。
自己看图，对，就是你！
这个问题我们还是先来请教一下砖家……
现在马上为我们连线场外的砖家……
嘟嘟嘟……
砖家您好，请问这位同学的问题您怎么看？
砖家：我趴在窗户上看……
……@#%&*!~~(@$%……
好了，原来砖家是说最近雾霾严重，所以他只能趴在窗户上看这个问题……
现在请听专家解读：
魔亦有道。
有专门的研究这些东西的，任何事只有专业领域的人做才会更有效率。
使用htmlpurifier才是终极理想。
http://www.xcoder.cn/index.php/archives/971
http://willko.iteye.com/blog/475493
http://www.piaoyi.org/php/html-purifier-php-xss.html
http://www.edu.cn/ji_shu_ju_le_bu_1640/20080717/t20080717_310285.shtml
http://www.111cn.net/phper/phpanqn/78018.htm
http://security.ctocio.com.cn/securitycomment/54/8222554.shtml
其实我还想说，我不希望防xss这种事情交给前端，模板语言来做，对于前端，给她用什么就用什么，用的不爽自己适当的做变量调节就可以了。给她们用，让她们用的爽，用的简单，这是我们好男人的责任和义务，大家说对不对啊，嘻嘻。
首先，我想说，不要用你的无知来挑战大家
这是道高一尺魔高一丈的东西
html中的编码:


javascript中的编码:


当然 htmlspecialchars 肯定是不行的，只能进行简单的处理，要不然还讨论什么xss了
the translations performed are:'&' (ampersand) becomes '&''' (double quote) becomes '' when ent_noquotes is not set.' (single quote) becomes ''' (or ') only when ent_quotes is set.'
上面代码还可以这样写
test
test
test
click test
但关键是，你确定你的那些代码可以提交吗？你要确定了再拿出来说
比如最简单的href加入以下代码基本上歇菜了

你到底有没有测试过,就说你提到的那些场景能够绕过htmlspecialchars呀,实践出真知.
#iu','$1>',$data); // remove javascript: and vbscript: protocols $data=preg_replace('#([a-z]*)[＼x00-＼x20]*=[＼x00-＼x20]*([`＼']*)[＼x00-＼x20]*j[＼x00-＼x20]*a[＼x00-＼x20]*v[＼x00-＼x20]*a[＼x00-＼x20]*s[＼x00-＼x20]*c[＼x00-＼x20]*r[＼x00-＼x20]*i[＼x00-＼x20]*p[＼x00-＼x20]*t[＼x00-＼x20]*:#iu','$1=$2nojavascript...',$data); $data=preg_replace('#([a-z]*)[＼x00-＼x20]*=([＼']*)[＼x00-＼x20]*v[＼x00-＼x20]*b[＼x00-＼x20]*s[＼x00-＼x20]*c[＼x00-＼x20]*r[＼x00-＼x20]*i[＼x00-＼x20]*p[＼x00-＼x20]*t[＼x00-＼x20]*:#iu','$1=$2novbscript...',$data); $data=preg_replace('#([a-z]*)[＼x00-＼x20]*=([＼']*)[＼x00-＼x20]*-moz-binding[＼x00-＼x20]*:#u','$1=$2nomozbinding...',$data); // only works in ie: $data=preg_replace('#(]+?)style[＼x00-＼x20]*=[＼x00-＼x20]*[`＼']*.*?expression[＼x00-＼x20]*＼([^>]*+>#i','$1>',$data); $data=preg_replace('#(]+?)style[＼x00-＼x20]*=[＼x00-＼x20]*[`＼']*.*?behaviour[＼x00-＼x20]*＼([^>]*+>#i','$1>',$data); $data=preg_replace('#(]+?)style[＼x00-＼x20]*=[＼x00-＼x20]*[`＼']*.*?s[＼x00-＼x20]*c[＼x00-＼x20]*r[＼x00-＼x20]*i[＼x00-＼x20]*p[＼x00-＼x20]*t[＼x00-＼x20]*:*[^>]*+>#iu','$1>',$data); // remove namespaced elements (we do not need them) $data=preg_replace('#*＼w+:＼w[^>]*+>#i','',$data); // http://www.111cn.net/ do{// remove really unwanted tags $old_data=$data; $data=preg_replace('#*(?:applet|b(?:ase|gsound|link)|embed|frame(?:set)?|i(?:frame|layer)|l(?:ayer|ink)|meta|object|s(?:cript|tyle)|title|xml)[^>]*+>#i','',$data); }while($old_data!==$data); // we are done... return $data;}
想要“完美”防御xss，就要每个开发都完全了解xss的知识，在合适的场景用合适的方案来编码
推荐参考：
https://www.owasp.org/index.php/xss_(cross_site_scripting)_prevention_cheat_sheet
任何用一个函数／一个库来解决这个问题的努力都是白日做梦。
重新再贴一边：
https://www.owasp.org/index.php/xss_(cross_site_scripting)_prevention_cheat_sheet
永远不可能完美防御，但至少可以挡住99%（剩下的1%才是最凶猛的～～～），目前的统一做法是，做好输入检查，良好的编程意识，安全转义，借助第三方安全库。不要信任输入。也不要信任输出。
为什么不用 csp 直接一了百了呢？