自适应布局&响应式布局
最近跟PM聊项目下一步发展，谈到了移动端网页，及移动端App的规划，期间就聊到了自适应布局，响应式布局，但是沟通中，觉得似乎这两个词一直是捆绑着，似乎在大家眼里自适应===响应式===一套代码走天下。
right？no，作为开发，很多时候我也把两个词混为一谈了，借着最近时间较为宽裕，整理下。
图摘自这里
自适应(Adaptive web design)
- 提出时间：2010年
- 理念：自动识别屏幕宽度，并作出相应调整的网页设计。
零宽字符妙用
发表于
更新于
本文字数：
712
阅读时长 ≈
1 分钟
本文介绍关于零宽字符妙用，包括使用场景、实现细节等，以提高关于零宽字符妙用的效率。
JS下的Promise
发表于
更新于
本文字数：
4k
阅读时长 ≈
7 分钟
本文是作者对JS下的Promise的介绍，包括JS下的Promise的优势、实现细节、相关资料等，这些步骤可以帮助作者提高JS下的Promise的效率。
Visual Studio Code插件清单
发表于
更新于
本文字数：
568
阅读时长 ≈
1 分钟
本文是作者对Visual Studio Code插件清单的介绍，包括Visual Studio Code插件清单的优势、实现细节、相关资料等，这些步骤可以帮助作者提高Visual Studio Code插件清单的效率。
同源,CSP与CORS
发表于
更新于
本文字数：
1.1k
阅读时长 ≈
2 分钟
本文介绍关于同源,CSP与CORS，包括使用场景、实现细节等，以提高关于同源,CSP与CORS的效率。
这三个词汇频繁出现在前端安全范畴，这里总结下。当然由这三个词汇还会串联出相关一些知识点，比如同站，跨域，XSS，CSRF等。
这些术语看着复杂多样，但是联系起来考虑他们实际的场景就很好理解了。
同源安全策略的出现
- 同源即协议，域名，端口均一致即是同源，不同源情况下发起异步请求即产生跨域，浏览器在保证安全起见，对于XHR，这类异步请求进行了同源安全策略限制。假如说没有同源的限制，那么A网站完全可以直接请求B网站的资源，A在未知情况下请求了流氓站点B的资源，B获得了A的数据，操作DOM等等，总之并不安全，因此同源限制是有必要的。但也需要知道，比如HTML中的Script，Img是没有同源限制的。
- 还是同样资源，如果是XHR发起的Script资源获取等，CSS中发起的font加载即会受到跨域限制。
同源虽好但是依然有缺陷，比如页面本身被注入了一些恶意脚本然后执行造成了XSS攻击，那么还是会破坏网站安全，这又如何保证呢，那么CSP就有作用了，CSP通过明确资源来源，资源类型等方式进一步确定了网站中资源的安全，比如CSP如果明确了只能是外链JS，那么即使注入了页内JS也会报错不执行。
如上同源安全策略+CSP就一定程度的保障了站点的安全，但是安全的同时也让灵活性得到了削弱，比如A站点如果确实就想访问B站点的资源，并且AB本身彼此很确定安全呢，那么CORS就来了，CORS确定了服务方明确了授权的被服务方，这样就可以达到资源复用的灵活。
- 面对同源限制，一种办法是CORS，一种是反向代理，因为后台服务是没有同源限制的，比如前端开发时，有时候请求的后端并不是本地，所以地址一定不同，会触发跨域，因此我们一般是配置了代理解决。
如一开始所说同源还是很严格的，但是比如一个企业它的网站有很多，比如a.111.com与b.111.com它们不同源，但是它们有时也需要一定程度的复用一些资源，如何做，同站的概念就出现了，同站只要求顶级域名一致即可。如果是同站，比如A站点中点击链接打开了B站点，因为同站，且具有同一个执行上下文，那么AB会复用同一个渲染进程，B站点下通过windw.opener是可以操作A站点窗口的。
有提到HTML中的Script，Img是没有同源限制的，那么有时资源会被盗用，又如何确保这些资源的安全呢，refer防盗链就出现了，HTTP请求时，请求头部会有refer资源，服务端根据refer可以进行403防盗处理。那如果refer可以被篡改，不就照样可以盗用资源了？因此，refer在浏览器端是不可以被篡改的。
写在最后
串起来这些之后可以明白这些技术是逐步发展，逐步在安全与便利性中取得得平衡。理解了就不难了。