前端源码安全
今天思考下前端源码安全的东西，不讲前端安全的大课题，只是针对于源码部分。
在我看来，源码安全有两点，一是防止抄袭，二是防止被攻破。
实际上，前端的代码大多是没有什么可抄袭性，安全更是形同虚设的（任何前端输入都是不能相信的）。但如果还是想防止源码被查看，HTML、CSS并不能做什么，最终都会用露出来（创新型的ShareWAF之类WAF类产品，可以做html整体加密，不在本文讨论之列），所以只能针对JS做文件的混淆加密。
关于抄袭
其实就前端来讲，多数代码没有什么好抄袭的，除了一些特效、游戏、前端展示性的类app功能，那么前端源码保护主要可以说为了防分析，防止人们知道其中逻辑，这里有两个案例：一个是之前锤子手机发布时的作弊丑闻，一个是小米手机在英国发布时的作弊事件，巧了，都是手机，都是作弊，都是前端JS代码引起的问题，被分析，曝光...，其实，做一下js混淆加密，这一切就都不会发生了，可惜了，这么大的公司，不注重前端安全，得不偿失啊。
混淆加密是防止其他人查看代码逻辑，生成的代码比原代码体积大一些，但现在的网速、机器性能、浏览器性能，完全不需要考虑这点性能损失。说了这么多，前端js代码混淆加密怎么做，推荐产品吧，国外有jscrmber，国内有jshaman。（推荐用国内的）！
关于安全
所有的用户输入都是不能相信的，如果后端的检查校验还做得不好，那就可能被攻破。前端代码的逻辑如果还被了解清楚，那就是雪上加霜。后端的问题我们前端管不着，前端的代码安全，就是用混淆加密解决，让别人看不懂。
HTML压缩
很少有人去做HTML的压缩（特指去除空白字符和注释），根据其他资料有几个原因：
1. HTML文档中，多个空白字符等价为一个空白字符。也就是说换行等空白字符的删除是不安全的，可能导致元素的样式产生差异。
2. HTML元素中，有一个pre, 表示 preformatted text. 里面的任何空白，都不能被删除。
3. HTML中有可能有 IE 条件注释。这些条件注释是文档逻辑的一部分，不能被删除。
也是鉴于上面几个原因，不提倡压缩HTML，通过服务器的gzip压缩就已经能达到很好的效果。
JS压缩合并混淆
在生产环境上，压缩合并是不必做的。但现在很多人都在做，号称是为了提高加载速度，事实上，不得不说：把多个html、css、js压缩成一个文件，这能快的了？原来一个文件100K，并行加载，是半行同时加载啊！2秒就加载完了。
压成一个后呢，经常可见的是达到好几MB，不能同时加载了，想想吧，是快了还是慢了，认为压成一个文件加载更快的人们啊，真得去交个智商税了。。。对单个js文件混淆加密就行了，不要压成一个文件，不要压成一个文件。重要的事情说两遍。
js代码混淆效果怎么样？
混淆加密前：
function hello(){
alert('hello');
}
用JShaman混淆加密后：
var
_0x08e6=['hello'];(function(_0x560c7b,_0x17e70b){var
_0x56bb8b=function(_0x4ccb21){while(--_0x4ccb21){_0x560c7b['\x70\x75\x73\x68'](_0x560c7b['\x73\x68\x69\x66\x74']());}};_0x56bb8b(++_0x17e70b);}(_0x08e6,0x77));var
_0x608e=function(_0x4d0ca4,_0x58e301){_0x4d0ca4=_0x4d0ca4-0x0;var
_0x50ffc7=_0x08e6[_0x4d0ca4];return _0x50ffc7;};function
hello(){alert(_0x608e('0x0'));}
绝对够用！
总结
1、前端安全需要重视，将来会越来越被重视，因为它真重要。
2、不要进行多文件压缩，不要把html、css、js压到一起，很不明智的做法。
3、前端安全，就是js代码安全，对js做混淆加密是正道！