Lei's Research
写了一个简单的个人主页，由于使用了一些 CSS3 的属性，考虑到浏览器兼容性问题，就使用了 webpack 的一些 loader 给这些属性加前缀。所以简单的静态单页面用了 webpack，又因为这个页面要放在 Github Pages 上，每次打包后还得手动切换分支推送到 Github 上，干脆趁这个机会写一个自动推送的脚本。
在移动端页面开发中，需要处理 Android 和 iOS 的兼容性问题。在 Chrome DevTools 中选择手机模式，可以一定程度上模拟移动端的页面，但更多的只是方便进行页面布局的调试和兼容。一些移动端的特性与表现，在真机和模拟情况下还是有存在很大差别的（比如软键盘的弹出等），尤其是 iOS 出于某些“考虑”表现出不符合标准的 BUG，在 Windows Chrome 中更是难以定位。
本文介绍如何在 Windows 系统中连接 iPhone Web 页面进行真机调试。
由于 Vue、React 等现代前端框架的前端 History 路由，在服务端并没有实际对应的物理路径和文件，所以使用 Nginx 的默认配置直接访问路由或刷新路由时，会导致 404 错误。
在前端开发中，终止一个已经开始的网路请求是有一定应用场景的。尤其是在 SPA (Signal Page Web Application) 单页面 Web 应用中，路由的跳转或场景的切换并不会像多页面跳转一样终止之前未被响应的网络请求。此时就可能会发生数据请求发生时的场景已经不存在，而网络请求成功后，数据被不正确的渲染在新的场景中的问题。因此应确保这些网络请求在场景变化后被终止或不被处理，以避免数据的混乱，提升部分性能。
当不使用外部插件时，webpack 会把 webpack.config.js
配置文件里每个入口打包一个 [entry].js
文件，这意味着单页面应用（单入口）最终只会打包生成一个 js
文件。而很多情况下，这种处理并不是最佳的处理方式。比如会造成单个
js 文件体积过大，并且每次项目迭代都会造成全量
js
的更新，不能充分利用缓存。所以我们需要按照一些规则，对打包输出的“块”进行拆分，已达到优化性能的目的。
Git 子模块具有一定的应用场景。
比如在一个项目 P 中，该项目被分为两部分，由 A 和 B 两个团队并行开发。而 B 团队开发的内容属于公共支持类的项目，不止会被该项目使用，其他项目也可能会使用。因此 B 团队开发的内容不可能和团队 A 共用一个仓库。因为这样的话别人拉取该公共内容时会连带拉取不需要的内容。而 A 团队项目的开发又依赖于 B 团队所做的内容，并希望能随时获得团队 B 得最新成果。
