&p&要搞清楚为什么要全网通，首先要了解一下3G时代，手机的制式是从3G网络普及以后，才开始变得泾渭分明的。&/p&&br&&p&在3G网络普及的时候，全世界最常用的是WCDMA，世界主流的国家都在用他。在我国是由联通运营，到了4G时代，这种模式升级以后改名叫作FDD-LTE模式，现在全世界的4G网络差不多都在用这种模式，除开中国。&/p&&br&&p&其次是CDMA 2000，主要是美国等一些国家支持，使用范围不及WCDMA广，在我国是电信运营。到了4G时代，CDMA2000已经放弃升级了，所以电信现在采用的是FDD-LTE和TDD-LTE的混合组网。&/p&&br&&p&然后再是TD-CDMA，这个是由我国自主开发的制式。由中国移动运营，到了4G时代进化成为TDD-LTE。（至于楼下有同学说TDD-LTE不是TD-SCDMA演进的，这个纯粹是个争论不休的话题，有兴趣的可以看&a href=&/question/& class=&internal&&TD-LTE 是 TD-SCDMA 的演进吗？ - AE-1&/a&）&/p&&br&&p&在3G时代，三种模式互不兼容，所以，在买手机的时候，我们才分为联通制式手机、移动版和电信版。联通版的手机不用说，主流制式，所有的手机一出来，必然先支持WCDMA。移动的手机，虽然国产的TD制式速度和稳定性不怎么样，鉴于移动是老大，所以支持他的手机也很多。反倒是电信的手机是最难买的，不过电信的网络反而是最稳定的，只是到了4G时代，因为高通弃更，用电信手机的就悲剧了。&/p&&br&&p&对于手机产商来说，原来同一款手机，他要做三种制式的版本出来。有些的三种制式用的芯片还不同，比如小米3，移动版就用的Nvidia Tegra4，联通版和电信版则用的是骁龙800。魅族则因为跟高通闹翻而经常没有电信版的机子，CDMA2000的核心技术掌握在高通手上。&/p&&br&&p&不同的芯片必然导致不同的体积，手机内部是寸土寸金的地方，则会产生不同的内部设计结构。根据不同的芯片，他们的系统还要进行不同的适配和调试，这是最麻烦的地方——比如说，Nvidia&/p&&p&做完了以后手机还要卖，当你开卖时，身为手机产商，他根据不同制式的手机做不同的库存。哪怕是做2种颜色，3种制式就需要估算6种不同的库存。库存留多了自己亏本，留少了消费者说你耍猴，事实上手机厂家经常处在两难的境地中。&/p&&br&&p&全网通则减少了这些流程，厂家只用设计一种内部结构就行了，系统也只用适配一个，大大简化了流程和成本。对于库存的预估也简单了很多，只用考虑颜色的因素，不用考虑不同制式给手机销量带来的影响。&/p&&br&&p&全网通对于消费者而言也是件好事，虽然一般的手机使用者不会频繁的更替卡，但是其中也不乏在使用期间转网的用户。比如我以前有个朋友就因为移动3G太慢而想转联通，因为手机只支持TD而一直只能忍着……出国的时候也不用因为不同的制式而转成2G网,任何网络都畅通无阻。二次使用率也将变高，比如我同事以前用的IPHONE5联通版，当她换了IPHONE6以后，旧手机丢给她老公但却用不了，因为她老公用的电信，全网通则不存在一个问题，不过，这很可能是导致手机销量下滑的一个因素……&/p&&br&&p&总体而言，全网通不论对手机厂商也好，消费者也罢，都是件极好的事情。在遥远的GSM时代，手机都不分你我，三家都用差不多的手机。到了3G时代，移动、联通、电信三家行成高高的壁垒，通常各自拉拢手机厂商，为自家移动制式定制手机。而到了4G时代，全网通开始流行起来，这个壁垒又开始变得模糊。所谓“天下之势，合久必分，分久必合”，大抵如是也。&/p&
要搞清楚为什么要全网通，首先要了解一下3G时代，手机的制式是从3G网络普及以后，才开始变得泾渭分明的。在3G网络普及的时候，全世界最常用的是WCDMA，世界主流的国家都在用他。在我国是由联通运营，到了4G时代，这种模式升级以后改名叫作FDD-LTE模式，现在…
先说自己的想法：从票价上不赚钱的，但是从其他方面的收入来补贴票价，实现盈利，属于多边商业模式。&br&&br&&b&1.“多跑几趟”，拓展更多场景&/b&&br&正如题主所说，目前各家的经营状况应该都是烧钱状态。从各家的承租公司来看，一辆车跑一天成本应该在1000元上下（大巴租赁价格参考：&a href=&///?target=http%3A///carshow.php%3Fcid%3D3%26id%3D31& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/carshow.php?&/span&&span class=&invisible&&cid=3&id=31&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&），新能源车可能更好些（充电省油费），但如果现在只做上下班场景的话，可以计算下，一辆50座的大巴，人均5元计算，满座率100%，上下班满打满算也只有500元，何况下班坐定制巴士的需求更少，所以理论上确实是烧钱的。&br&那么如果满座率100%的情况下，更多的则可能要考虑将一天的车用于更多的用途，把租车一天的剩余价值彻底发挥出来。可以想象到的比如：&br&1）定制巴士圈住了更多的是上下班白领人士，而白领中午吃饭比较挑剔，周边地沟油满足不了，可以尝试和一些优质商家合作分成，定向输送到某些地方吃饭，打旗号“走远点，吃好点”&br&2）承接一些周边游，机场巴士或者地铁接驳巴士，尽量让租的车一直在路上跑&br&3）和一些演唱会等人流量巨大的合作，做散场时的交通疏散，解决散场打不到的的用户痛点也可以同时把钱赚了。&br&4）做企业的定制上下班路线，保证尤其是晚上一定的上座率。&br&&br&&b&2.广告是不变的主题&/b&&br&公交车的车身广告比地铁在广告上的好处就在于是移动的，容易吸引用户眼球（运动物体更容易吸引）且视觉面积大，即使是较远的距离也可以很好的传递广告信息。&br&&img src=&/fdb_b.png& data-rawwidth=&734& data-rawheight=&283& class=&origin_image zh-lightbox-thumb& width=&734& data-original=&/fdb_r.png&&&br&如果结合你的线路是走比较人流量集中的线路，广告价值也就大大提升了。举公交广告为例，一个好的线路确实获得挺可观的收入。&br&&img src=&/3e0ff78f02a_b.png& data-rawwidth=&894& data-rawheight=&662& class=&origin_image zh-lightbox-thumb& width=&894& data-original=&/3e0ff78f02a_r.png&&&br&&img src=&/9116dba4fb0121a72aafa2_b.png& data-rawwidth=&865& data-rawheight=&403& class=&origin_image zh-lightbox-thumb& width=&865& data-original=&/9116dba4fb0121a72aafa2_r.png&&当然，不仅车身是一个可以做广告的地方，车内饰都可以尝试成为广告的曝光场景。&br&&br&&b&3.增值服务&/b&&br&如果说用户及时舒适上下班是基本需求，那么让用户在车上过的爽，提供差异性服务就是另外一种思路了。比如：&br&1）上班通勤的用户希望能晚起，而且在车上可以比较舒适，那么如果为用户提供早餐，让用户在路上舒适的睡觉之前还可以吃早餐不用折腾去买，也算是比较人性化的服务。这有点像看电影-爆米花模式，电影本身可能并不赚钱，盈利则在爆米花上。&br&2）另外由于定位精准上下班白领用户，那么可以尝试在车上做一些白领喜爱的，比如面膜试用，美食试吃，一方面可以通过这些获得广告收入，另外一块也可以形成差异化服务。&br&3）另外车上提供wifi除了可以是让用户获取更好的体验，另外也可以通过wifi做一些广告或应用下载。&br&&br&&b&4.物流&/b&&br&由于提供服务的班次有限，是否把物流也可以纳入，利用大巴特有的低箱做同城物流，从而收取运输费用？&br&&br&暂时想到这些，欢迎交流。
先说自己的想法：从票价上不赚钱的，但是从其他方面的收入来补贴票价，实现盈利，属于多边商业模式。1.“多跑几趟”，拓展更多场景正如题主所说，目前各家的经营状况应该都是烧钱状态。从各家的承租公司来看，一辆车跑一天成本应该在1000元上下（大巴租赁价…
很多答案是从使用上讲的，我加两个技术方面的。&br&&ol&&li&搜索引擎需要对抓取到的结果进行管理。当索引结果越来越多时，保证存储和查询速度，保证数万台服务器内容一致的难度越来越高。Google于03至06年左右公布了三篇论文，描述了GFS、BigTable、MapReduce三种技术以解决这些问题。由于Google并没有公布算法细节，因此由雅虎牵头，在06年左右建立了开源项目Hadoop，目的是根据Google的三篇论文，实现一个大规模的管理计算系统。但直到08年，Hadoop同Google公布的一些关键指标仍有几倍的差距。百度曾经由王选院士的一个博士带领，想基于Google论文独立实现(金字塔计划)一个自己的系统，但开发难度过大项目夭折，最终也转向了Hadoop。如今，Amazon、Facebook、Yahoo包括百度都在大规模应用Hadoop，而Google已经从2010年开始迁移到新的三驾马车Caffeine、Pregel、Dremel上了。单就搜索技术而言，Google不是领先百度，而是领先全世界。&/li&&li&年，Google公布了世界上第一个全球化的数据库系统Spanner，这套系统将分布在全球各地的数据中心连接到一起，利用原子钟和GPS，打破了地理间隔，实现了全球规模具有一致性和实时性的数据库。在Google之前，很多人认为这种系统不可能做出来，但Google做到了[1]。&/li&&/ol&&p&另外，除了搜索，Google在深度学习和机器人方面也是全球领先的，尤其是后者。尽管百度也有深度学习研究院，但在这两方面跟Google比起来完全是空白。&/p&&br&&p&事实上，让百度来和谷歌比是很不公平的，搜索只是Google的一个部门，但却是百度一整个公司。Google的竞争对手是Apple、Amazon、Facebook和Microsoft，百度的竞争对手是360、搜狗。Google没了搜索，还有Chrome、Android、Youtube，百度没了搜索，那就什么都没有了。&br&&/p&&br&&p&[1]
&a class=& wrap external& href=&///?target=http%3A///wiredenterprise/2012/11/google-spanner-time/all/& target=&_blank& rel=&nofollow noreferrer&&Exclusive: Inside Google Spanner, the Largest Single Database on Earth&i class=&icon-external&&&/i&&/a&&/p&
很多答案是从使用上讲的，我加两个技术方面的。搜索引擎需要对抓取到的结果进行管理。当索引结果越来越多时，保证存储和查询速度，保证数万台服务器内容一致的难度越来越高。Google于03至06年左右公布了三篇论文，描述了GFS、BigTable、MapReduce三种技术以…
其实何止是Chrome, 几乎所有的浏览器厂商都在淘汰/去掉NPAPI的支持&br&&br&&img src=&/832d5ceecb748ddfd1ee07e_b.png& data-rawwidth=&870& data-rawheight=&141& class=&origin_image zh-lightbox-thumb& width=&870& data-original=&/832d5ceecb748ddfd1ee07e_r.png&&&br&&blockquote&&i&Opera: 我早就说了啊&/i&&/blockquote&&img src=&/202bbf44ef1ce6ec6dbdf_b.png& data-rawwidth=&989& data-rawheight=&108& class=&origin_image zh-lightbox-thumb& width=&989& data-original=&/202bbf44ef1ce6ec6dbdf_r.png&&&blockquote&&i&火狐 :我还是会支持的，只是大家要一起来淘汰这个技术.&/i&&/blockquote&&br&如果我告诉你 Flash 也是NPAPI插件，你会不会是这个样子&br&&img src=&/691fe24ef0acbf6b2b2db2_b.png& data-rawwidth=&656& data-rawheight=&510& class=&origin_image zh-lightbox-thumb& width=&656& data-original=&/691fe24ef0acbf6b2b2db2_r.png&&&br&那么 NPAPI 到底出了什么问题？&br&&br&NPAPI全称叫 Netscape plugin API，
你没有看错，就是那个当年被微软一棒子打死了好多年的 Netscape。&br&&br&很久以前， Netscape 发明了NPAPI 这个种架构，来帮助浏览器渲染一些HTML没有的东西。比如 PDF, 比如 视频， 以及等等。。&br&&br&事实上， NPAPI 插件架构是个非常好的架构， 一共就40几个API,
相对于另外一种浏览器插件架构: ActiveX来说，简直就是业界良心。&br&&br&&b&这里只有一个问题，它的发明时间是 1995 年，而在那个时候手机还可以砸死人，学校的电脑房要穿鞋套才能进。&/b&&br&&br&那个时代所有类似的API设计者几乎都很自然的忽略掉了安全性问题。那个时候无论是网络环境还是商业环境相比现在都简单很多。&br&&br&我们来看看NPAPI插件和浏览器的关系是什么, 同时对比下和同样执行网络下载代码的 Javascript 引擎的位置，&br&&img src=&/19a1fadbbde5ff_b.png& data-rawwidth=&579& data-rawheight=&324& class=&origin_image zh-lightbox-thumb& width=&579& data-original=&/19a1fadbbde5ff_r.png&&&br&&br&看懂了吧， 你以为是NPAPI是插件是吗？其实它和浏览器是平级运行的，它甚至可以打开网页，给你安一个木马，然后随手帮你关掉杀毒软件。什么，你说NPAPI不就40几个API嘛， 少年，你想多了，NPAPI不限制插件自由访问系统所有的API.&br&&br&而 Javascript 引擎的限制就多得多，事实上，Chromium 系列的浏览器 Javascript 引擎均是运行在沙盒之中，一举一动都是被严密监视着的，敢有异常? 浏览器分分钟杀死你。&br&&br&除了安全性以外，插件们还质量参差不齐，一旦崩溃浏览器就得跟着一起崩掉。 于是各个浏览器又一把鼻涕一遍泪的把插件们放到另外一个进程中运行，惹不起你们我们还躲不起嘛。其他的耗电量，图形效率，脚本效率一类的我就不多讲了，讲多了都是泪。&br&&br&&b&&i&不过如果只是安全，那你把插件放到沙箱里面隔离起来不就行了嘛。&/i&&/b&&br&&br&是的，谷歌当年也是这样想的，于是他们发明了 PPAPI， 然后在业界里面振臂一呼，大家来看，我的这个新API好啊，插件用起来更安全，有沙箱哦。&br&&br&这个是业界伙伴们的态度:&br&&img src=&/29ecb1f5976d30dce26a7df_b.png& data-rawwidth=&576& data-rawheight=&213& class=&origin_image zh-lightbox-thumb& width=&576& data-original=&/29ecb1f5976d30dce26a7df_r.png&&&br&&i&Java: 我最近听说Chrome不支持我们了，大家请换浏览器，就这样&/i&&br&&img src=&/36b8dbe8b23ade33c5f6_b.png& data-rawwidth=&682& data-rawheight=&121& class=&origin_image zh-lightbox-thumb& width=&682& data-original=&/36b8dbe8b23ade33c5f6_r.png&&&br&&i&火狐: 我们对 PPAPI(pepper) 一点兴趣都木有。&/i&&br&&i&(而且坑爹的是， Google 的PPAPI链接居然指的是Mozilla 的这个页面。不知道是不是存心恶心Mozilla).&/i&&br&&br&如果你是个程序猿又有一颗好奇的心，表示无法理解PPAPI为何如此不受待见，你可以去这里看看PPAPI的文档 ，在这里&br&&a href=&///?target=https%3A///p/ppapi/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/p/ppapi&/span&&span class=&invisible&&/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&你一定会发现问题，其实不管你是不是程序猿你都会发现问题。因为，这个PPAPI官方文档链接里面，几乎木有文档。。&br&&br&不过Adobe认怂了。 事实上Adobe很早就开始发布PPAI的版本。&br&&img src=&/0e6eb440cba8cd39a2eed8_b.png& data-rawwidth=&399& data-rawheight=&409& class=&content_image& width=&399&&&br&&br&所以如果你这几天再看到插件无法运行的对话框，如果上面写的是Flash, 你只需要去下载一个最新的ppai的flash 插件，或者下载一个新版的Chrome.
因为目前Chrome已经开始内置PPAPI版的Flash。&br&&br&其他的，就看厂商们如何跟进吧。&br&&br&========================================================================&br&&br&总结来讲：&br&NPAPI 会被禁掉， 不过PPAPI会被继续支持，于是：&br&&ul&&li&Java Plugin 需要重写&br&&/li&&li&UnityPlugin 需要重写&br&&/li&&li&SliverLight Plugin 需要重写。&br&&/li&&/ul&用到以上插件的网站会收到影响。&br&使用 Flash 插件的网站不会收到影响， 因为 Flash 已经重写了。。&br&&br&下面是 Google 对 流行NPAPI 的统计数据：&br&&img src=&/efdd925a6f8a71fbc8ed2_b.png& data-rawwidth=&413& data-rawheight=&139& class=&content_image& width=&413&&&br&所以，普遍性就是：&br&如果你还在用任何一款NPAPI插件，然后对应的插件还没有PPAI版本或者HTML 替代版的话。9月以后节哀顺变吧。。
其实何止是Chrome, 几乎所有的浏览器厂商都在淘汰/去掉NPAPI的支持Opera: 我早就说了啊火狐 :我还是会支持的，只是大家要一起来淘汰这个技术.如果我告诉你 Flash 也是NPAPI插件，你会不会是这个样子那么 NPAPI 到底出了什么问题？NPAPI全称叫 Netscape plug…
谢邀。经常用，所以过来回答一下。&br&&br&我的看法是：&u&PC上用的价值不大，移动端单页面应用(也有叫webapp)值得尝试。&/u&&br&&br&这里要首先提出一个关于静态资源管理和SEO(搜索引擎优化)方面的关联问题：&u&如果要做SEO，那么CSS必然不能进行LS(localstorage)的本地缓存优化&/u&。这个原因很简单：&br&&br&要进行SEO，必须直接输出完整HTML，因此必须让样式在头部以link标签加载。如果先输出HTML，后用js从本地缓存读取样式再插入，会出现严重的阻塞和闪烁问题，相信正常人是不会这么干的。&br&&br&然后再更正一件事，就是取出localstorage的代码不一定要eval，eval很evil，一个eval函数很有可能影响整个js文件的压缩（出现eval之后不能对变量名进行替换），当然，我们可以通过一些hack避免这种压缩问题，不过我喜欢这样搞：&br&&div class=&highlight&&&pre&&code class=&language-js&&&span class=&kd&&var&/span& &span class=&nx&&script&/span& &span class=&o&&=&/span& &span class=&nb&&document&/span&&span class=&p&&.&/span&&span class=&nx&&createElement&/span&&span class=&p&&(&/span&&span class=&s1&&'script'&/span&&span class=&p&&);&/span&
&span class=&kd&&var&/span& &span class=&nx&&code&/span& &span class=&o&&=&/span& &span class=&s1&&'!function(){'&/span& &span class=&o&&+&/span& &span class=&nx&&getCodeFromLocalStorage&/span&&span class=&p&&()&/span& &span class=&o&&+&/span& &span class=&s1&&'\n}();'&/span&&span class=&p&&;&/span&
&span class=&nx&&script&/span&&span class=&p&&.&/span&&span class=&nx&&appendChild&/span&&span class=&p&&(&/span&&span class=&nb&&document&/span&&span class=&p&&.&/span&&span class=&nx&&createTextNode&/span&&span class=&p&&(&/span&&span class=&nx&&code&/span&&span class=&p&&));&/span&
&span class=&nb&&document&/span&&span class=&p&&.&/span&&span class=&nx&&head&/span&&span class=&p&&.&/span&&span class=&nx&&appendChild&/span&&span class=&p&&(&/span&&span class=&nx&&script&/span&&span class=&p&&);&/span&
&/code&&/pre&&/div&没测过效率，应该跟eval没多大差别，真正的性能损耗还是在LS的读取上。&br&&br&再来解答一个困惑：相比浏览器原生的缓存，LS还有什么优势呢？本来，最棒的浏览器缓存是本地强缓存，我在另外一个知乎答案中解释过本地强缓存的终极用法：&a href=&/question//answer/& class=&internal&&大公司里怎样开发和部署前端代码？ - 张云龙的回答&/a& 工程化实践起来有一定的难度，我也在那篇回答里提到了，用户主动触发的页面刷新行为（比如刷新按钮、右键刷新、F5等），会导致浏览器放弃本地缓存，使用协商缓存（304缓存），用了LS之后，可以完全避免这种情况，等效于无视用户主动刷新行为的本地强缓存。当LS+eval速度大于304协商速度时，LS方案具有统计上的正收益。&br&&br&此外，讨论缓存问题不能单看一次读取，要从整个缓存的生命周期观察。浏览器缓存以url为单位，一个url可能对应多个文件的打包，N个文件合并成一个url，假设每个文件更新的概率是P，那么整个url缓存失效的概率就是&img src=&///equation?tex=1-%281-P%29%5E%7BN%7D+& alt=&1-(1-P)^{N} & eeimg=&1&&，随着合并文件的增多，每次上线url缓存失效的可能性会非常高，而如果采用LS，配合combo服务，加上精细到文件甚至字符级别的缓存控制，就能让版本迭代过程中缓存的命中率大大提高。&br&&br&还有，缓存问题也绝不是一个页面的问题，网站很多页面之间会跳转访问，彼此之间也有共享的静态资源，基于url的缓存让跨页面之间缓存共享问题变得粗粒度。举个例子，有A、B两个页面，彼此有访问路径（比如百度首页和搜索结果页之间的访问），其中：&br&&ul&&li&A页面使用资源：a, b, c, d&/li&&li&B页面使用资源：a, b, c, e, f&/li&&/ul&假设不考虑并发请求的优化，我们希望尽可能的打包，再假设A页面是主要入口，那么，最合理的方案可能就是a-b-c-d打包（设为[abcd]），e-f打包（设为[ef]），从而使得：&br&&ul&&li&A页面使用url：[abcd]&/li&&li&B页面使用url：[abcd]+[ef]&/li&&/ul&由于用户大多首次访问A页面，然后会跳转到B页面，所以访问A页面会很快，再跳转到B页面可以从缓存中使用[abcd]包，再只需加载[ef]包即可。为了更大的缓存利用率，我们让B页面复用A页面的url缓存，但多了一个不需要的d资源这也是合理的。也就是说，基于url的缓存利用可能在有些情况下会资源的冗余加载。想想那些通过url直接访问B页面的用户来说，无缓存情况下，页面加载的是[abcd]+[ef]两个资源包，既有冗余，又是两个请求，这并不是最理想的加载策略（这个方案是倾向于优化A页面展现的，虽然B页面首次展现不理想，但B页面大部分pv是从A页面导入，网站总体性能是更好的）。&br&&br&而使用combo服务+LS的情况就不同了，假设combo的url的形式是[a,b,c,...]，那么单独访问A、B页面的资源url就是：&br&&ul&&li&A页面使用url：[a,b,c,d]&/li&&li&B页面使用url：[a,b,d,e,f]&/li&&/ul&用户由A页面进入网站，加载[a,b,c,d]这个url，然后LS缓存4个资源，再跳转到B页面，缓存控制框架可以知道本地缓存了哪些，然后只发起[e,f]这个请求。其效果基本等效于浏览器基于URL的缓存。而对于那些没有通过A页面直接访问B页面的用户来说，B页面加载的是[a,b,d,e,f]，也是不错的合并策略。LS在这个时候就发挥了那么一点点优势。&br&&br&当然，这种优势还不够明显，最能展现LS优势的，其实是单页面应用。因为单页面应用需要完全有JS管理页面状态，并增量加载资源，用户也可能通过带有hash的url直接访问某个单页面中的虚拟页面，同一个页面会有很多种不同的资源请求组合，这个时候，唯有LS+combo才能很好的解决资源加载与缓存问题。对于这种情况，我有一个网站可以用于展示效果：&br&&br&&a href=&///?target=http%3A//scrat-team.github.io/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Scrat - webapp模块化开发体系&i class=&icon-external&&&/i&&/a&&br&&br&这是部署在github上的页面，没有combo服务，但是可以一定程度上展现LS缓存的效果，我把js、css都缓存到LS中了，有兴趣的同学可以查看这个webapp中不同页面间的 &b&首次访问&/b&、&b&二次访问&/b&、&b&页面间跳转&/b& 等过程中资源的加载效果。这个网页的源代码在这里：&a href=&///?target=https%3A///scrat-team/scrat-site& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&scrat-team/scrat-site · GitHub&i class=&icon-external&&&/i&&/a& 通过travis-ci自动构建到这里的：&a href=&///?target=https%3A///scrat-team/scrat-team.github.io& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&scrat-team/scrat-team.github.io · GitHub&i class=&icon-external&&&/i&&/a&&br&&br&总结一下&br&&br&PC上应用价值不大的原因在于：&br&&ul&&li&兼容性不太好，不支持LS的浏览器比例仍然很大&/li&&li&网络速度快，协商缓存响应快，LS读取+eval很多时候会比不上304&/li&&li&通常需要SEO，导致css不能缓存，仅缓存js使得整个缓存方案意义进一步减小&/li&&li&浏览器本地缓存足够可靠持久&/li&&li&跨页面间共享缓存即便有浪费也差别不大&/li&&/ul&移动端webapp值得一试的原因在于：&br&&ul&&li&兼容性好&/li&&li&网速慢，LS读取+eval大多数情况下快于304&/li&&li&都说是webapp了，不需要seo，css也可以缓存，再通过js加载&/li&&li&浏览器缓存经常会被清理，LS被清理的几率低一些&/li&&li&以模块文件为单位，缓存失效率低&/li&&li&不同页面状态直接访问、二次访问、页面状态跳转资源组合是不确定的，不能通过url来缓存资源，否则就不“增量”啦&/li&&/ul&另外，LS缓存作为缓存，我们要先假设它是不可靠的，使用原则就是“LS缓存存在就用，没有就直接加载”，就是所谓的平稳退化（或渐进增强）。那些“写满了”，“写不了”，“被清了”等情况一概当做没有缓存。从统计的角度来看，在合适的模式下开启缓存全局总是有正收益的&br&&br&顺便做个广告，以下UC的产品都是使用这套模块化开发体系进行开发的，后端均为nodejs，UC的前端开发者大多为全栈工程师：&br&&ul&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&神马视频&i class=&icon-external&&&/i&&/a&&br&&/li&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&NBA 常规赛赛季&i class=&icon-external&&&/i&&/a&&br&&/li&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&2014年巴西世界杯&i class=&icon-external&&&/i&&/a&&/li&&/ul&还有一些UC only的产品就不贴了，不方便查看源代码和网络情况。。。&br&&br&最后感慨一下：&br&&blockquote&前端性能优化既是一个工程问题，又是一个统计问题。&br&&/blockquote&&br&===============[ 补充 ]===============&br&收到一些反馈，这里做一下补充：&br&&ul&&li&这是一种“黑科技”，因为LS本身并不是被设计用来干这件事的。从过往历史来看，任何黑科技都是短暂且不可靠的，但就在当下，我也想不到什么更好的工程手段来提升移动端webapp的性能，所以，LS+combo的方案可以说是“有总比没有强”&/li&&li&在未来，HTTP2时代的到来应该会完美绝杀这种黑科技，因此，工程化的具体实施方法必然要与时俱进，不过工程化的方法论不会过时，无论在哪个时代，我们都应该全面、科学的分析工程问题，结合当前的浏览器环境和技术手段来做方案，保持网站的性能&/li&&li&有安全领域大神 &a href=&///?target=http%3A///etherdream& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&@EtherDream&i class=&icon-external&&&/i&&/a& 指出，“&a href=&///?target=http%3A////C77wEket1& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&静态资源存 localStorage 就是水坑漏洞的前兆，风险远远大于优化&i class=&icon-external&&&/i&&/a&”，这点我也认可，一旦有xss漏洞，就会被人利用将恶意代码注入到LS中，导致即便修复了xss恶意代码也存在的问题。所以我们现在采用的策略是每次部署新版本就会清除全部缓存。这会导致缓存利用率的下降，不过至少还有部分浏览器缓存在呢，算是一个折中处理。&/li&&li&腾讯网前端团队做的 &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&MT&i class=&icon-external&&&/i&&/a& 方案利用LS把更新机制精细到了字符级别，这个确实更加“丧心病狂”，哈哈。不过看到他们运行的很不错，应该是更加优秀的缓存控制方案。&/li&&li&可编程的缓存控制，我觉得这是一个值得深挖的方向，对前端的工程化价值非常大，尤其是与统计结合起来，根据网站的访问统计、页面间的步长关系计算出最合理的缓存和打包策略，这也是一种方向，【基于统计的资源打包+浏览器缓存】几乎可以完败【combo+LS】，不过这套系统的基础设施建设成本颇高&/li&&li&TBC&/li&&/ul&
谢邀。经常用，所以过来回答一下。我的看法是：PC上用的价值不大，移动端单页面应用(也有叫webapp)值得尝试。这里要首先提出一个关于静态资源管理和SEO(搜索引擎优化)方面的关联问题：如果要做SEO，那么CSS必然不能进行LS(localstorage)的本地缓存优化。这…
关于创业团队成员的薪水与待遇，似乎一直都是一个敏感话题。一种说法是既然创业就应该承担前期收益风险，另一种观点则是薪水红利不应成为发展重点。之前在 @纯银 的博客扫过一片博文，我觉得是这个问题的答案。&br&&br&原文地址:&a href=&///?target=http%3A//firecacada./blog/static//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&firecacada.&/span&&span class=&invisible&&/blog/static//&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&谈创业者的待遇，首先要明确两件事情。第一，你是创始人或者共同发起此事的创始团队吗？如果是，通常会更信任长期回报，愿意接受短期内的低薪。比如我和搭档都表态说，领点基本生活费就好了，情况紧急时不领钱甚至倒贴钱也行。&br&&br&第二，你是创业团队的第一批加入者？还是第二、三、四、五批？加入的时间越早(因为公司资本不足)，通常薪水越低，但能领到更多的期权，或是更低的行权价格。相当于用个人风险来换取长期回报。&br&&br&我之前四处请教创业者，听到过各种关于创业薪酬的说法。有人说，刚开始最多只领到之前70%的，也有人说70%都太高，50%就差不多了，还有人说待遇上不能愧对兄弟们——不过也只是中型公司的中等水平而已。&br&&br&(这样讲多半会被别人戳脊梁骨，觉得资本家的心真是黑透了)&br&&br&换个角度看，如果项目你喜欢，团队也合得来，管理上非常的友善，任务合理授权充分，工作氛围好/环境好/发展前景好，最后还能拿到一线大公司的薪酬，这简直是发票刮出1万元的完美结局。我要是能蹭到这状态我还辞什么职创什么业……&br&&br&所谓创业，必定要承担三种风险。资金风险，通常由风险投资商来消化；个人品牌风险，通常由创始人来消化；收益风险，通常由全体创业团队来消化。这些风险当然都是有回报的——如果创业顺利。&br&&br&拿 收益举例，初始团队全员期权基本上是行规。如果创业顺利，我觉得比较合理的期权回报是“正常薪水的1-3倍”，相当于你认为自己值月薪10K，加入创业团 队2年，那么期权收入在24-72万比较心理平衡，还是不考虑上市或高价收购等变态好下场的情况。和这份收益对应的风险，则是初始阶段只拿“正常薪水的 50%-70%”。&br&&br&完整点讲，以上减薪幅度也得先看看你的原始收入。比如之前只领5k，不仅不高甚至还偏低，那么就没必要减薪。但如果之前领20k呢，刚开始创业，压根烧不起钱，不减薪的话人力成本很快就压沉了船。大家抱在一起落水淹死。&br&&br&忽然想写这个话题，是因为在组队过程中，有两位条件非常好的大公司的朋友，期待值是年薪20-30万。这两位朋友都很有能耐，我相信他们在大公司里一定值这 个身价。不过，我的回复和建议是，他们可以试试自己发起创业，而不是加入别人发起的团队。如果项目是自己牵头来做的，满怀信心与期待，就比较容易削减自己 的收入来控制成本，延长第一笔融资的使用时间。&br&&br&如果按照大公司身价来组队，哪怕只是七八人的小队， 一年的人力成本也会飙升到200多万(+四金)，再加上其他成本，一年起码烧掉300万，18个月成本预算是500万——坦率说按照现在的行情，恐怕很难 谈下来这一笔天使投资。而且VC也很难信任你，觉得有享乐主义的倾向，事儿还没谱钱倒是哗哗的，不像一个创业的样子。&br&&br&什 么叫创业的样子？我觉得至少有一点就是，相信回报在未来，而不是当下。当下的牺牲会换回未来若干倍的回报。再说这种牺牲也只是暂时的，比如6-18个月拿 到了A轮融资，通常是两三千万人民币，全员薪资就可以回调到正常水平。这时再算算期权，发现空头支票居然已经值好几十万，并随着B轮，C轮公司估值翻倍而 不断升值。&br&&br&创业伊始，家底甚薄。用风险兑换前景几乎是一个定律。没有不承担风险的额外的收益，但常 见最后竹篮打水的艰苦的付出。稳定，薪酬优厚，环境优美，这些都是大公司的优势——创业则全然反之。它更接近寻宝海盗的大冒险，输的概率远远大过赢的概 率。也许正因为此才希望旱涝保收，但这既不是创业的心态，也不是(天使轮)创业团队能承担得了的成本。&br&&br&所 以跟联系我的朋友交流时，我讲得最多的是项目本身。你可以多问我一些关于产品的问题，尽管问，我耐心作答。加入这支创业小队的动机除了你对创业的向往，对 我和Quake的信任，更重要的是对项目本身的可行性评估。希望你在审慎权衡各种风险因素后，会觉得这条路走通的概率比较高，同时也是比较愉快的一次旅 程。顺理成章的，怀有“信心”也意味着你重视未来的回报更甚于当下。&br&&br&今天跟一位联系我的朋友在电话里谈起薪资的话题。我能接受的数值比她之前的薪水低一些，还好低得不太多，只少1k，不过年终奖就会少很多。我解释说，6-18个月后拿到A轮的话，奖金不是什么问题吧，拿不到A轮咱们就挂了……&br&&br&比 空头支票式的远景描绘更重要的是，你觉得一直向往的创业经历，是否值得自己接受短期内的薪水下调。说真的，创业顺利的太少，失败的太多。我真不愿意跟你画 “期权/融资/上市/发财”这张大饼。比如我这次选择创业，自己投了几十万进去，月薪还不足之前的1/3。难道我有必胜的信心吗？当然没有的，我只是特别 想追求一段快意人生的创业经历，自由自在去做我喜欢的事情罢了。是的，“自由”几乎是创业公司唯一的优势。在富丽堂皇的大公司被『捆』得久了，才明白自由 的可贵。你愿意为了这段探险旅程本身而承担多少风险，付出多少代价？&br&&br&前些日子，一个老朋友跟我说，高薪其实也是枷锁。他的工资比我高，薪水这玩意儿(在心理上)一旦上去了就很难下得来，收入比以前少便郁郁不乐。但这同时也限制了你的选择，一定得赚更多的钱，一定得步步高升，一定得……&br&&br&赚更多的钱是不是你生命中最重要的事情？&br&&br&我这么问，想必大部分人都会给出否定的回答。但想是一回事，做出选择又是另一回事。所以高薪确实是一道枷锁，让你的职业选择越来越窄，越发纠结。&br&&br&话 说到这里，必须得澄清一下，深夜话痨并不是为了压价。对于预期年薪20-30万的朋友，我诚挚的建议是，自己发起创业，或者加入另一只成熟期的，可能已经 拿到了B轮的创业团队。后者有可能开出与大公司相当的薪资，代价是更少的期权，更高的行权价，以及失去了从零开始培育一款产品的机会。前5个创业成员会决 定产品的气质、命运与团队文化，这种亲生亲养的快乐，可能不是每个人都看重的，即便看重可能也不值得你冒如此大的风险。但恰恰是特别看重“亲生亲养”的 人，才能经历最刺激的创业旅程。拿我现在做的产品方向打个比方，从第20位之后加入的同伴相当于“跟团旅游”。跟团和自助游的区别，你们懂得。&br&&br&没什么结论，我只是深更半夜大发感慨罢了。国外一个科技博客作者曾写道：“为什么喜欢创业？因为我们是一群愚蠢的海盗。”看到这句话的时候，我有一种胸口碎大石的悸动。
关于创业团队成员的薪水与待遇，似乎一直都是一个敏感话题。一种说法是既然创业就应该承担前期收益风险，另一种观点则是薪水红利不应成为发展重点。之前在 @纯银 的博客扫过一片博文，我觉得是这个问题的答案。原文地址:谈创业者的待遇…
不知道楼主你指的是哪方面的出路？&br&首先对口的工作几乎没有lisp相关的，即使有工作机会也是非常少的，领域相对非常窄的。&br&像国内冰河之流还是极少数的。lisp是一门对程序员创造能力要求非常高的语言，而且如果使用这门语言做开发的话，项目会不可控。因为市场上的人才太少了，程序员写代码不是一个人完成一个项目，是需要协作的，如果都用lisp你上哪里找那么多喜欢用圆括号代码交流的人？我以前看了一些lisp的库，发现 framewok 类的东西太少了。这一点不难理解，因为lisp 这门语言中 hack技巧太多了。强大的宏功能几乎使得多人的项目几乎无法协作。另外lisp这玩意的初衷就没有考虑过要去面向大众，它只会怎么好使怎么来。&br&但是，lisp中的编程思想是异常强大的。像闭包，垃圾收集，匿名函数等这一类强大的功能都是lisp发明出来。lisp里面一些思想相对于平常过程式语言能使用极少的代码就能完成相对强大的功能。我们应该学习他的思想去解决我们平常在项目中碰到的问题。现在的javascript，ruby，python一类的语言都具有lisp中的函数式特性。掌握这些技巧可以让我们在抽象层面更好的解决一些问题。&br&所以lisp这玩意还真不是拿来给你找出路找工作的。
不知道楼主你指的是哪方面的出路？首先对口的工作几乎没有lisp相关的，即使有工作机会也是非常少的，领域相对非常窄的。像国内冰河之流还是极少数的。lisp是一门对程序员创造能力要求非常高的语言，而且如果使用这门语言做开发的话，项目会不可控。因为市场…
没人邀请，看到这个问题不错，路过怒答。（多图预警）&br&&br&前百度工程师，曾负责百度 &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&前端集成解决方案&i class=&icon-external&&&/i&&/a& 的核心设计与开发工作。我现在称这个领域为【前端工程】。没错，这是我最爱唠叨的问题域。&br&&br&这是一个非常有趣的 &u&&b&非主流前端领域&/b&&/u&，这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题，入行到现在一直在学习和实践中。&br&&br&在我的印象中，facebook是这个领域的鼻祖，有兴趣、有梯子的同学可以去看看facebook的页面源代码，体会一下什么叫工程化。&br&&br&接下来，我想从原理展开讲述，多图，较长，希望能有耐心看完。&br&&br&&br&---------------------------- 我是一条分割线 ----------------------------&br&&br&&img src=&/07c2bdef6ccef3ada425d61e3062dd09_b.jpg& data-rawwidth=&389& data-rawheight=&238& class=&content_image& width=&389&&&br&&br&让我们返璞归真，从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css，用文本编辑器写代码，无需编译，本地预览，确认OK，丢到服务器，等待用户访问。前端就是这么简单，好好玩啊，门槛好低啊，分分钟学会有木有！&br&&br&&img src=&/d53b504bbc9f1887eddf06d_b.jpg& data-rawwidth=&400& data-rawheight=&98& class=&content_image& width=&400&&&br&&br&然后我们访问页面，看到效果，再查看一下网络请求，200！不错，太(TM)完美了！那么，研发完成。。。。了么？&br&&br&等等，这还没完呢！对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不“好玩”。&br&&br&看看那个a.css的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样：&br&&br&&img src=&/6a8ca252211cec85a31ac4_b.jpg& data-rawwidth=&401& data-rawheight=&98& class=&content_image& width=&401&&&br&利用304，让浏览器使用本地缓存。但，这样也就够了吗？不成！304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，变成这样：&br&&br&&img src=&/fd74ab2bf02d79dd7aff180e_b.jpg& data-rawwidth=&400& data-rawheight=&98& class=&content_image& width=&400&&&br&强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信。好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？&br&&br&很好，相信有人想到了办法：&b&&u&通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源&/u&&/b&。好像这样：&br&&br&&img src=&/8ad1ade55f5_b.jpg& data-rawwidth=&304& data-rawheight=&110& class=&content_image& width=&304&&&br&下次上线，把链接地址改成新的版本，就更新资源了不是。OK，问题解决了么？！当然没有！大公司的变态又来了，思考这种情况：&br&&br&&img src=&/7dc885bf_b.jpg& data-rawwidth=&579& data-rawheight=&310& class=&origin_image zh-lightbox-thumb& width=&579& data-original=&/7dc885bf_r.jpg&&&br&页面引用了3个css，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？！&br&&br&重新开启变态模式，我们不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。&br&&br&什么东西与文件内容相关呢？我们会很自然的联想到利用 &a href=&///?target=http%3A///view/.htm& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&数据摘要要算法&i class=&icon-external&&&/i&&/a& 对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把url改成带摘要信息的：&br&&br&&img src=&/dbc1d_b.jpg& data-rawwidth=&588& data-rawheight=&310& class=&origin_image zh-lightbox-thumb& width=&588& data-original=&/dbc1d_r.jpg&&&br&这回再有文件修改，就只更新那个文件对应的url了，想到这里貌似很完美了。你觉得这就够了么？大公司告诉你：图样图森破！&br&&br&唉~~~~，让我喘口气&br&&br&现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径：&br&&br&&img src=&/0866cb58bcfa06b162e0d91_b.jpg& data-rawwidth=&574& data-rawheight=&259& class=&origin_image zh-lightbox-thumb& width=&574& data-original=&/0866cb58bcfa06b162e0d91_r.jpg&&&br&好了，当我要更新静态资源的时候，同时也会更新html中的引用吧，就好像这样：&br&&br&&img src=&/16d6d6c32e52ef1d1a835fb2ed15f864_b.jpg& data-rawwidth=&574& data-rawheight=&456& class=&origin_image zh-lightbox-thumb& width=&574& data-original=&/16d6d6c32e52ef1d1a835fb2ed15f864_r.jpg&&&br&这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？&br&&ol&&li&&b&&u&先部署页面，再部署资源&/u&&/b&：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。&br&&/li&&li&&b&&u&先部署资源，再部署页面&/u&&/b&：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。&/li&&/ol&好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。&br&&br&但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！&br&&br&这个奇葩问题，起源于资源的 &u&&b&覆盖式发布&/b&&/u&，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 &u&&b&非覆盖式发布&/b&&/u&。&br&&br&&img src=&/9b3a9df114d14a14130a70abf5733837_b.jpg& data-rawwidth=&631& data-rawheight=&456& class=&origin_image zh-lightbox-thumb& width=&631& data-original=&/9b3a9df114d14a14130a70abf5733837_r.jpg&&&br&看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。&br&&br&所以，大公司的静态资源优化方案，基本上要实现这么几个东西：&br&&br&&blockquote&&ol&&li&配置超长时间的本地缓存
—— 节省带宽，提高性能&br&&/li&&li&采用内容摘要作为缓存更新依据
—— 精确的缓存控制&br&&/li&&li&静态资源CDN部署
—— 优化网络请求&br&&/li&&li&更资源发布路径实现非覆盖式发布
—— 平滑升级&br&&/li&&/ol&&/blockquote&&br&全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在&b&&u&前端所有静态资源加载的位置都要做这样的处理&/u&&/b&。是的，所有！什么js、css自不必说，还要包括js、css文件中引用的资源路径，由于涉及到摘要信息，引用资源的摘要信息也会引起引用文件本身的内容改变，从而形成级联的摘要变化，大概示意图就是：&br&&br&&img src=&/edf10bb428d39d721e1e_b.jpg& data-rawwidth=&709& data-rawheight=&371& class=&origin_image zh-lightbox-thumb& width=&709& data-original=&/edf10bb428d39d721e1e_r.jpg&&&br&好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这(TM)让工程师怎么写码啊！！！&br&&br&要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。或者大家可以去我的blog看其中的一些拆解：&a href=&///?target=https%3A///fouber/blog& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&fouber/blog · GitHub&i class=&icon-external&&&/i&&/a&&br&&br&&blockquote&总之，前端性能优化绝逼是一个工程问题！&br&&/blockquote&&br&以上不是我YY的，可以观察 百度 或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。&br&&br&建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？&br&&br&另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，&u&&b&大家总是把自己不关心的问题丢给别人&/b&&/u&，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！&br&&br&妈妈，我再也不玩前端了。。。。5555&br&&br&&br&&br&========================[ 10.29更新 ]========================&br&这里更新一下：&br&&br&在评论中， &a data-hash=&4b1a0d3f97fddca9ed6fc820a7be261c& href=&///people/4b1a0d3f97fddca9ed6fc820a7be261c& class=&member_mention& data-editable=&true& data-title=&@陈钢& data-tip=&p$b$4b1a0d3f97fddca9ed6fc820a7be261c&&@陈钢&/a&&a data-hash=&aed& href=&///people/aed& class=&member_mention& data-editable=&true& data-title=&@fleuria& data-tip=&p$b$aed&&@fleuria&/a& @林翔 提到了rails，刚刚去看了一下，确实是完成了以上所说的优化细节，对整个静态资源的管理上的思考于本答案描述的一致。很遗憾我直到今天（）才了解到rails中的assets pipeline。这里向以上3位同学道歉，原谅我的无知。&br&&br&不过整篇回答没有讲解到具体的解决方案实现思路，只是介绍了前端在工程化方向的思考，答案本身是可用的，了解rails的人也可以把此答案当做是对rails中assets pipeline设计原理的分析。&br&&br&rails通过把静态资源变成erb模板文件，然后加入&%= asset_path 'image.png' %&，上线前预编译完成处理，不得不承认，fis的实现思路跟这个几乎完全一样，但我们当初确实不知道有rails的这套方案存在。&br&&br&相关资料：英文版：&a href=&///?target=http%3A//guides.rubyonrails.org/asset_pipeline.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&The Asset Pipeline&i class=&icon-external&&&/i&&/a&，中文版：&a href=&///?target=http%3A//guides.ruby-china.org/asset_pipeline.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Asset Pipeline&i class=&icon-external&&&/i&&/a&&br&========================[ 10.31更新 ]========================&br&用 &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&F.I.S&i class=&icon-external&&&/i&&/a& 包装了一个小工具，完整实现整个回答所说的最佳部署方案，并提供了源码对照，可以感受一下项目源码和部署代码的对照。&br&源码项目：&a href=&///?target=https%3A///fouber/static-resource-digest-project& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&fouber/static-resource-digest-project · GitHub&i class=&icon-external&&&/i&&/a&&br&部署项目：&a href=&///?target=https%3A///fouber/static-resource-digest-project-release& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&fouber/static-resource-digest-project-release · GitHub&i class=&icon-external&&&/i&&/a&&br&部署项目可以理解为线上发布后的结果，可以在部署项目里查看所有资源引用的md5化处理。&br&&br&这个示例也可以用于和assets pipeline做比较。fis没有assets的目录规范约束，而且可以以独立工具的方式组合各种前端开发语言（coffee、less、sass/scss、stylus、markdown、jade、ejs、handlebars等等你能想到的），并与其他后端开发语言结合。&br&&br&assets pipeline的设计思想值得独立成工具用于前端工程，fis就当做这样的一个选择吧。
没人邀请，看到这个问题不错，路过怒答。（多图预警）前百度工程师，曾负责百度
的核心设计与开发工作。我现在称这个领域为【前端工程】。没错，这是我最爱唠叨的问题域。这是一个非常有趣的 非主流前端领域，这个领域要探索的是如何用工…
已有帐号？
无法登录？
社交帐号登录