10被浏览471分享邀请回答3添加评论分享收藏感谢收起12 条评论分享收藏感谢收起\ 老手们要序列化，小伙子要json，到底哪个更好？
老手们要序列化，小伙子要json，到底哪个更好？
PHP开发工程师
这位童鞋很懒，什么也没有留下～～！
序列化与json性能评测
日常工作中需要在数据库中存储一些结构数据，常用的方法有两种，一是序列化（serialize），二是json格式。
两者各有优缺点，比如序列化支持对象格式、序列化后的数据会保存数据类型和数据个数。而json格式相比序列化的数据更短，并且前后端交互时适用性也更好。
但在实际的项目中，应该用哪种格式来存储数据呢？网上说法不一，老手们更倾向于序列化(可能是因为json格式是在PHP5.2之后才引进的)，而年轻小伙们更倾向于json（可能他们没听说过序列化)，今天抛开其他的不谈，只从性能上看看，哪种格式性能更好。
测试日期：日
测试机：MacBook Pro（13 英寸，2015 年初期）
CPU：2.7 GHz Intel Core i5
内存：8 GB 1867 MHz DDR3
PHP版本：PHP 5.6.15
测试步骤：
1.小数据的序列化和json压缩
2.小数据的序列化和json解压缩
3.大数据的序列化和json压缩
4.大数据的序列化和json解压缩
测试方法：
每次测试循环10次，每个操作循环10000次
测试结论在最下面，测试代码在最最下面，对数据没兴趣的小伙伴可以直接拉到最下面
小数据压缩
[1,2,3,4,5,6,7,8,9,0]
小数据解压缩
序列化：a:10:{i:0;i:1;i:1;i:2;i:2;i:3;i:3;i:4;i:4;i:5;i:5;i:6;i:6;i:7;i:7;i:8;i:8;i:9;i:9;i:0;}
JSON：[1,2,3,4,5,6,7,8,9,0]
大数据压缩
怕影响排版，只放上网址，可以复制后查看
http://api.mooninbox.com/api4/?api=goods/all
大数据解压缩
怕影响排版，只放上网址，可以复制后查看
http://api.mooninbox.com/api4/?api=goods/all
在小数据压缩方面，json比序列化快了近1倍，而其他方面序列化比json都要快一些，特别是大数据解压缩这一块整整快了4倍。
有了这些数据支持，你会怎么选呢？
反正我是会用json，拿到json之后直接丢给前端或者移动端,让他们自己去处理吧，理由就是“服务端的性能很宝贵，哈哈哈”
function ser($data)
$ret = '';
while($i & 10000) {
$ret = serialize($data);
function unser($data)
$ret = '';
while($i & 10000) {
$ret = unserialize($data);
function json($data)
$ret = '';
while($i & 10000) {
$ret = json_encode($data);
function unjson($data)
$ret = '';
while($i & 10000) {
$ret = json_decode($data,true);
$short = [1,2,3,4,5,6,7,8,9,0];
set_time_limit(0);
while($i&10) {
$start = microtime(true);
$ret = ser($arr);
$end = microtime(true);
echo $end - $
echo '&/br&';
对我的内容感兴趣，可以听听我在慕课网的课程哦
更多文章也欢迎来我的个人BLOG
相关标签：
请登录后，发表评论
评论（Enter+Ctrl）
评论加载中...
评论加载中...
Copyright (C) 2018 imooc.com All Rights Reserved | 京ICP备 号-2我的职业是前端工程师【七】：你真的懂前后端分离吗？a year ago前端在一个 API 请求之后，可以直接渲染这些数据成 HTML。在这个时候，我们仍然可以看到，上面数据中的 date 字段值
的格式，和我们日常用的 2017 年 3 月 4 号的不一样。所以，我们需要在前端引入 moment 这样的库，然后解析这个值。如果仅仅是这样的处理，那么应该由后台帮我们转换这个值。与此同时，后台应该按时间来对博客进行排序。前端只需要遍历这个数组，随后取出相应的值显示即可，不需要做任何的逻辑处理。遗憾的是，在真正的项目中开发的时候，并不能达到这么完美的状态。特别是，为了提高用户体验时，我们可能就会将数据存储在本地，随后直接操作这些数据，对其进行排序，筛选等等的操作。除此，还有诸如表格、图表等等的高级样式，也需要处理这些数据。而当用户需要提交数据的时候，这些逻辑就会落到前端上。不可避免的前端逻辑：表单如果一个前端应用只显示数据的话，那么这个应用就没有充足的理由，做成一个单页面应用——单页面应用是为了更好的交互而存在的。当我们注册、登录、购买东西时，就需要开始与表单进行处理。合理的表单验证模式应该是：双边验证。前端在用户输入的过程中就需要实时地检查，是否带有特殊符号、值是否是在允许的范围内、是不是符合相应的规范等等。而不是等用户填写完内容并提交后，再由服务端来告诉用户说，“你的用户名不符合规范”。服务在收到前端收到的数据后，不管前端有没有进行验证，都应该按后台的逻辑进行验证。于是乎在这个时候，这些逻辑就被无可避免地放到前台里了。欢迎在豆瓣专栏上鼓励我：赞赏还没有人赞赏，快来当第一个赞赏的人吧！153收藏分享举报文章被以下专栏收录如何成为一个前端设计师{&debug&:false,&apiRoot&:&&,&paySDK&:&https:\u002F\u002Fpay.zhihu.com\u002Fapi\u002Fjs&,&wechatConfigAPI&:&\u002Fapi\u002Fwechat\u002Fjssdkconfig&,&name&:&production&,&instance&:&column&,&tokens&:{&X-XSRF-TOKEN&:null,&X-UDID&:null,&Authorization&:&oauth c3cef7c66aa9e6a1e3160e20&}}{&database&:{&Post&:{&&:{&isPending&:false,&contributes&:[{&sourceColumn&:{&lastUpdated&:,&description&:&2017 年 1 月份，看完村上春树的新书《我的职业是一个小说家》，我便萌发了写一个《我的职业是前端工程师》系列文章的想法——以个人视角来看前端领域的各种技术。\n\n每周日，准时更新~~&,&permission&:&COLUMN_PUBLIC&,&memberId&:2055680,&contributePermission&:&COLUMN_PUBLIC&,&translatedCommentPermission&:&all&,&canManage&:true,&intro&:&如何成为一个前端设计师&,&urlToken&:&beafe&,&id&:27524,&imagePath&:&v2-54f861c7e0d899bf5744bda5bce1b171.jpg&,&slug&:&beafe&,&applyReason&:&0&,&name&:&我的职业是前端工程师&,&title&:&我的职业是前端工程师&,&url&:&https:\u002F\u002Fzhuanlan.zhihu.com\u002Fbeafe&,&commentPermission&:&COLUMN_ALL_CAN_COMMENT&,&canPost&:true,&created&:,&state&:&COLUMN_NORMAL&,&followers&:3551,&avatar&:{&id&:&v2-54f861c7e0d899bf5744bda5bce1b171&,&template&:&https:\u002F\u002Fpic4.zhimg.com\u002F{id}_{size}.jpg&},&activateAuthorRequested&:false,&following&:false,&imageUrl&:&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-54f861c7e0d899bf5744bda5bce1b171_l.jpg&,&articlesCount&:18},&state&:&accepted&,&targetPost&:{&titleImage&:&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-167c7e86af8fae_r.jpg&,&lastUpdated&:,&imagePath&:&v2-167c7e86af8fae.jpg&,&permission&:&ARTICLE_PUBLIC&,&topics&:[,707],&summary&:&前后端不分离，是怎样的？大概也只有我们这些『老古董』们，才对此有更多感受。不对，那些写 React 的人，可能会对此也有一些体会。今天，如果有一个前端工程师说，不知道前后端分离是什么。那么，要么是刚毕业不久的，要么是从老版的公司里出来的员工，要…&,&copyPermission&:&ARTICLE_COPYABLE&,&translatedCommentPermission&:&all&,&likes&:0,&origAuthorId&:0,&publishedTime&:&T20:54:33+08:00&,&sourceUrl&:&&,&urlToken&:,&id&:2413003,&withContent&:false,&slug&:,&bigTitleImage&:false,&title&:&我的职业是前端工程师【七】：你真的懂前后端分离吗？&,&url&:&\u002Fp\u002F&,&commentPermission&:&ARTICLE_ALL_CAN_COMMENT&,&snapshotUrl&:&&,&created&:,&comments&:0,&columnId&:27524,&content&:&&,&parentId&:0,&state&:&ARTICLE_PUBLISHED&,&imageUrl&:&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-167c7e86af8fae_r.jpg&,&author&:{&bio&:&待我代码编成，娶你为妻可好 @花仲马&,&isFollowing&:false,&hash&:&fea2f801ab1dc87a87f8bdeb6fdb3394&,&uid&:20,&isOrg&:false,&slug&:&phodal&,&isFollowed&:false,&description&:&工程师 \u002F 咨询师 \u002F 作家 \u002F 设计学徒&,&name&:&phodal&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fphodal&,&avatar&:{&id&:&cebfe26a7aecb4&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},&memberId&:2055680,&excerptTitle&:&&,&voteType&:&ARTICLE_VOTE_CLEAR&},&id&:567400}],&title&:&我的职业是前端工程师【七】：你真的懂前后端分离吗？&,&author&:&phodal&,&content&:&\u003Cblockquote\u003E\u003Cp\u003E前后端不分离，是怎样的？大概也只有我们这些『老古董』们，才对此有更多感受。不对，那些写 React 的人，可能会对此也有一些体会。\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cp\u003E今天，如果有一个前端工程师说，不知道前后端分离是什么。那么，要么是刚毕业不久的，要么是从老版的公司里出来的员工，要么是刚从时光机里出来的。\u003C\u002Fp\u003E\u003Ch2\u003E前后端分离\u003C\u002Fh2\u003E\u003Cp\u003E我刚开始接触前后端分离的时候，正值它开始慢慢扩散的时候，也还没有意识到它带来的好处。觉得它甚是麻烦，当我改一个接口的时候，我需要同时修改两部分的代码，以及对应的测试。反而，还不如直接修改原有的模板来得简单。\u003C\u002Fp\u003E\u003Cp\u003E可是当我去使用这个，由前后端分离做成的单页面应用时，我开始觉得这些是值得。当页面加载完后，每打开一个新的链接时，不再需要等网络返回给我结果；我也能快速的回到上一个页面，像一个 APP 一样的体现这样的应用。整个过程里，我们只是不断地从后台去获取数据，不需要重复地请求页面——因为这些页面的模板已经存在本地了，我们所缺少的只是实时的数据。\u003C\u002Fp\u003E\u003Cp\u003E后来，当我从架构去考虑这件事时，我才发现这种花费是值得的。\u003C\u002Fp\u003E\u003Ch3\u003E什么是前后端分离？\u003C\u002Fh3\u003E\u003Cp\u003E前后端分离和微服务一样，渐渐地影响了新的大型系统的架构。微服务和前后端分离要解决是类似的问题，\u003Cstrong\u003E解耦\u003C\u002Fstrong\u003E——可以解耦复杂的业务逻辑，解耦架构。可要是说相像吧，消息队伍和前后端便相似一些，通过传递数据的形式来解耦组件。\u003C\u002Fp\u003E\u003Cp\u003E前后端分离意味着，\u003Cstrong\u003E前后端之间使用 JSON 来交流，两个开发团队之间使用 API 作为契约进行交互\u003C\u002Fstrong\u003E。从此，后台选用的技术栈不影响前台。当后台开发人员选择 Java 的时候，我可以不用 JSP 来编写前端页面，继续使用我的 React 又或者 Angular。而我使用 React 时，也不影响后台使用某一个框架。\u003C\u002Fp\u003E\u003Ch1\u003E概念我们已经清楚了，但是还有一个问题：我们真的需要前后端分离吗？\u003C\u002Fh1\u003E\u003Ch3\u003E真的需要前后端分离吗？\u003C\u002Fh3\u003E\u003Cp\u003E过去，听说 TDD (Test-driven development，测试驱动开发) 可以改善代码的质量，我们便实施了 TDD；接着，听说 BDD (Behavior-driven development，行为驱动开发) 可以交付符合业务需求的软件，我们便实施了 BDD；后来，听说 DDD (Domain-driven design，领域驱动设计) 可以分离业务代码与基础代码，我们便实施了 DDD。今天，听说了前后端分离很流行，于是我们就实施了前后端分离——这就是传说中的 HDD（Hype-driven Development，热闹驱动开发）。\u003C\u002Fp\u003E\u003Cp\u003E前后端分离在过去的两三年里，确实特别的热闹。但是我们怎么才能知道，是不是需要这样的架构呢？\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E\u003Cstrong\u003E页面交互是否复杂 ？\u003C\u002Fstrong\u003E 是简单的提供页面给用户浏览？或者想要支持复杂的用户操作？\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E是否需要搜索引擎优化？\u003C\u002Fstrong\u003E如果需要的话，那么从一开始我们就需要考虑后端渲染。\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E能提升开发效率吗？\u003C\u002Fstrong\u003E如果不能有效的提升开发效率，为什么要作死呢？\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E是否会提供 API 给 APP？\u003C\u002Fstrong\u003E如果我们已经有一个 API 提供给 APP，那么要做这件事就很容易了。如果未来会有的话，那么我们更应该尝试去分离。\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E前端的修改是不是非常频繁？\u003C\u002Fstrong\u003E如果不需要经常修改的话，那么这种优化便没有优势。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E当然了，如果老板说，我们需要前后端分离，那就做呗！很多时候，一些技术决策都会由于战略原因，而发生一些有意思的变化。\u003C\u002Fp\u003E\u003Ch3\u003E前后端分离将遇到的那些挑战\u003C\u002Fh3\u003E\u003Cp\u003E而，当我们决定需要前后端分离时，我们仍然还需要面对一系列的问题：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E\u003Cstrong\u003E是否足够的安全？\u003C\u002Fstrong\u003E如果我们设计出来的架构不够安全，那么这一系列的操作都是白搭。我们怎么去存储用户数据，使用 LocalStorage 的话，还要考虑加密。采用哪种认证方式来让用户登录，并保存相应的状态？\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E是否有足够的技术来支撑前后端分离？\u003C\u002Fstrong\u003E有没有能力创建出符合 RESTful 风格的 API？\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E是否有能力维护 API 接口？\u003C\u002Fstrong\u003E当前端或者后台需要修改接口时，是否能轻松地修改。\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E前后端协作的成本高不高？\u003C\u002Fstrong\u003E前端和后台两个团队是不是很容易合作？是不是可以轻松地进行联调？\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E前后端职责是否能明确？\u003C\u002Fstrong\u003E即：\u003Cstrong\u003E后台提供数据，前端负责显示\u003C\u002Fstrong\u003E。\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003E是否建立了前端的错误追踪机制？\u003C\u002Fstrong\u003E能否帮助我们快速地定位出问题。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E当我们在不同的项目组上尝试时，就会发现主要的挑战是沟通上的挑战，而非技术上的局限。\u003C\u002Fp\u003E\u003Ch2\u003E前后端分离的核心：后台提供数据，前端负责显示\u003C\u002Fh2\u003E\u003Cp\u003E我曾经有过使用 PHP 和 Java 开发后台代码的经历，仍然也主要是集中在前端领域。在这样的传统架构里，编写前端页面可不是一件容易的事。后台只会传给前端一个 ModelAndView，然后前端就要扑哧扑哧地去丰富业务逻辑。\u003C\u002Fp\u003E\u003Cp\u003E传统的 MVC 架构里，因为某些原因有相当多的业务逻辑，会被放置到 View 层，也就是模板层里。换句话来说，就是这些逻辑都会被放到前端。我们看到的可能就不是各种if、else还有简单的equal判断，还会包含一些复杂的业务逻辑，比如说对某些产品进行特殊的处理。\u003C\u002Fp\u003E\u003Cp\u003E如果这个时候，我们还需要做各种页面交互，如填写表单、Popup、动态数据等等，就不再是简单的和模板引擎打交道了。我们需要编写大量的 JavaScript 代码，因为业务的不断增加，仅使用 jQuery 无法管理如此复杂的代码。\u003C\u002Fp\u003E\u003Ch3\u003E输出逻辑：数据显示\u003C\u002Fh3\u003E\u003Cp\u003E而仅仅只是因为逻辑复杂的前端代码，无法影响大部分团队进行前后端分离——因为它没有业务价值。实际上是先有了单页面应用，才会出现前后端分离。单页面应用可以让用户不需要下载 APP，就可以拥有相似的体现。并且与早期的移动网页相比，拥有更好的体验。\u003C\u002Fp\u003E\u003Cp\u003E为了达到这样的目的，后台似乎返回对应的 Model 即可，稍微修改一下 Controller 的逻辑，然后返回这些数据。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cdiv class=\&highlight\&\u003E\u003Cpre\u003E\u003Ccode class=\&language-text\&\u003E\u003Cspan\u003E\u003C\u002Fspan\u003E[{\n
\&content\&: \&\&,\n
\&date\&: \&\&,\n
\&description\&: \&前后端分离，你应该知道的八件事\\r\\n\\r\\n前后端不分离，是怎样的？大概也只有我们这些『老古董』们，才对此有更多感受。不对，那些写 React 的人，可能会对此也有一些体会。\&,\n
\&id\&: 1,\n
\&slug\&: \&iamafe-frontend-backend\&,\n
\&title\&: \&我的职业是前端工程师:
前后端分离，你应该知道的八件事\&,\n
\&user\&: \&\&\n}]\n\u003C\u002Fcode\u003E\u003C\u002Fpre\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E前端在一个 API 请求之后，可以直接渲染这些数据成 HTML。在这个时候，我们仍然可以看到，上面数据中的 date 字段值
的格式，和我们日常用的 2017 年 3 月 4 号的不一样。所以，我们需要在前端引入 moment 这样的库，然后解析这个值。如果仅仅是这样的处理，那么应该由后台帮我们转换这个值。\u003C\u002Fp\u003E\u003Cp\u003E与此同时，后台应该按时间来对博客进行排序。前端只需要遍历这个数组，随后取出相应的值显示即可，不需要做任何的逻辑处理。\u003C\u002Fp\u003E\u003Cp\u003E遗憾的是，在真正的项目中开发的时候，并不能达到这么完美的状态。特别是，为了提高用户体验时，我们可能就会将数据存储在本地，随后直接操作这些数据，对其进行排序，筛选等等的操作。除此，还有诸如表格、图表等等的高级样式，也需要处理这些数据。\u003C\u002Fp\u003E\u003Cp\u003E而当用户需要提交数据的时候，这些逻辑就会落到前端上。\u003C\u002Fp\u003E\u003Ch3\u003E不可避免的前端逻辑：表单\u003C\u002Fh3\u003E\u003Cp\u003E如果一个前端应用只显示数据的话，那么这个应用就没有充足的理由，做成一个单页面应用——单页面应用是为了更好的交互而存在的。当我们注册、登录、购买东西时，就需要开始与表单进行处理。\u003C\u002Fp\u003E\u003Cp\u003E合理的表单验证模式应该是：\u003Cstrong\u003E双边验证\u003C\u002Fstrong\u003E。\u003C\u002Fp\u003E\u003Cp\u003E前端在用户输入的过程中就需要实时地检查，是否带有特殊符号、值是否是在允许的范围内、是不是符合相应的规范等等。而不是等用户填写完内容并提交后，再由服务端来告诉用户说，“你的用户名不符合规范”。\u003C\u002Fp\u003E\u003Cp\u003E服务在收到前端收到的数据后，不管前端有没有进行验证，都应该按后台的逻辑进行验证。\u003C\u002Fp\u003E\u003Cp\u003E于是乎在这个时候，这些逻辑就被无可避免地放到前台里了。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E欢迎在豆瓣专栏上鼓励我：\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fread.douban.com\u002Fcolumn\u002F2F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E我的职业是前端工程师\u003C\u002Fa\u003E\u003C\u002Fp\u003E&,&updated&:new Date(&T12:54:33.000Z&),&canComment&:false,&commentPermission&:&anyone&,&commentCount&:24,&collapsedCount&:0,&likeCount&:153,&state&:&published&,&isLiked&:false,&slug&:&&,&lastestTipjarors&:[],&isTitleImageFullScreen&:false,&rating&:&none&,&titleImage&:&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-167c7e86af8fae_r.jpg&,&links&:{&comments&:&\u002Fapi\u002Fposts\u002F2Fcomments&},&reviewers&:[],&topics&:[{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&前端工程师&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&前端入门&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&程序员&}],&adminClosedComment&:false,&titleImageSize&:{&width&:1280,&height&:720},&href&:&\u002Fapi\u002Fposts\u002F&,&excerptTitle&:&&,&column&:{&slug&:&beafe&,&name&:&我的职业是前端工程师&},&tipjarState&:&activated&,&tipjarTagLine&:&真诚赞赏，手留余香&,&sourceUrl&:&&,&pageCommentsCount&:24,&tipjarorCount&:0,&annotationAction&:[],&hasPublishingDraft&:false,&snapshotUrl&:&&,&publishedTime&:&T20:54:33+08:00&,&url&:&\u002Fp\u002F&,&lastestLikers&:[{&bio&:&尽人事 听天命&,&isFollowing&:false,&hash&:&865fba9b2ab&,&uid&:60,&isOrg&:false,&slug&:&zhu-dan-ni-42&,&isFollowed&:false,&description&:&&,&name&:&朱丹妮&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fzhu-dan-ni-42&,&avatar&:{&id&:&&,&template&:&https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:null,&isFollowing&:false,&hash&:&67637af75decdc57a713ad&,&uid&:68,&isOrg&:false,&slug&:&li-yan-69-51&,&isFollowed&:false,&description&:&&,&name&:&李彦&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fli-yan-69-51&,&avatar&:{&id&:&v2-26cfcd949d22dc6330cf1a&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:&假的&,&isFollowing&:false,&hash&:&02cb212b9cc435d8a3d2df3a1bbddd04&,&uid&:592800,&isOrg&:false,&slug&:&3-&,&isFollowed&:false,&description&:&向前走，就这么走，就算会错过什么。&,&name&:&王鹏&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002F3-&,&avatar&:{&id&:&v2-ccc90f565a87&,&template&:&https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:&&,&isFollowing&:false,&hash&:&a89ef3b043a7c70d0a27efeddaadb151&,&uid&:92,&isOrg&:false,&slug&:&czhacker&,&isFollowed&:false,&description&:&不以目标上的勤奋掩盖行动上的懒惰\n不以环境上的假象掩盖内心里的懒惰\n不以社交上的泛滥抱怨时间上的匮乏\n一事对一事，一物对一物。&,&name&:&Tomdsa&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fczhacker&,&avatar&:{&id&:&bbb7d5c2b53c311bbcad04&,&template&:&https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:&程旭媛&,&isFollowing&:false,&hash&:&dd53eef99ee7e40cc3c1e0f&,&uid&:468400,&isOrg&:false,&slug&:&chen-xian-sheng-41-3&,&isFollowed&:false,&description&:&&,&name&:&陈先生&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fchen-xian-sheng-41-3&,&avatar&:{&id&:&da8e974dc&,&template&:&https:\u002F\u002Fpic4.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false}],&summary&:&前后端不分离，是怎样的？大概也只有我们这些『老古董』们，才对此有更多感受。不对，那些写 React 的人，可能会对此也有一些体会。今天，如果有一个前端工程师说，不知道前后端分离是什么。那么，要么是刚毕业不久的，要么是从老版的公司里出来的员工，要…&,&reviewingCommentsCount&:0,&meta&:{&previous&:{&isTitleImageFullScreen&:true,&rating&:&none&,&titleImage&:&https:\u002F\u002Fpic1.zhimg.com\u002F50\u002Fv2-32d523e822f1a948441c_xl.jpg&,&links&:{&comments&:&\u002Fapi\u002Fposts\u002F2Fcomments&},&topics&:[{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&前端入门&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&程序员&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&前端工程师&}],&adminClosedComment&:false,&href&:&\u002Fapi\u002Fposts\u002F&,&excerptTitle&:&&,&author&:{&bio&:&待我代码编成，娶你为妻可好 @花仲马&,&isFollowing&:false,&hash&:&fea2f801ab1dc87a87f8bdeb6fdb3394&,&uid&:20,&isOrg&:false,&slug&:&phodal&,&isFollowed&:false,&description&:&工程师 \u002F 咨询师 \u002F 作家 \u002F 设计学徒&,&name&:&phodal&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fphodal&,&avatar&:{&id&:&cebfe26a7aecb4&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},&column&:{&slug&:&beafe&,&name&:&我的职业是前端工程师&},&content&:&\u003Cblockquote\u003E\u003Cp\u003E要成为一个优秀的前端工程师，需要什么技能和学习？答案：练习\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cp\u003E在逛知乎、SegmentFault 又或者是相似的技术社区，我们总会看到类似的问题。新手总会关注于，需要怎样的技能，怎么才能入门？有一点经验的程序员则是，需要练习什么？如若一个程序员已经懂得问题的关键是，编程需要大量的练习。那么，我想这个程序员已经入了这个行道了。\u003C\u002Fp\u003E\u003Cp\u003E在我成为所谓的『前端工程师』之前，我没有想到会变成这样的结果。\u003C\u002Fp\u003E\u003Ch2\u003E前端项目的练习过程\u003C\u002Fh2\u003E\u003Cp\u003E年少的时候，想要做的是 Kernel Hacker。大学时，我做点前端相关的兼职，顺便赚钱点钱。再用这点钱，买点硬件做一些底层、低级的编程，带着去实验室，拿着电洛铁，高喊着：让我们来做一个毁灭世界的机器人。好在，后来我离这个行当有点远，要不这个世界可能就岌岌可危了。反而因此倒是，学会了相当多的前端知识，以及在今天看来是屠龙之术的 IE 兼容。\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-36d183ebe6f93db87a76_b.jpg\& data-rawwidth=\&872\& data-rawheight=\&285\& class=\&origin_image zh-lightbox-thumb\& width=\&872\& data-original=\&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-36d183ebe6f93db87a76_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E随后，在研究数据可视化时，我看着用 JavaScript、HTML、CSS 可以做出这么炫的效果。我就继续回到图形编程这个行当，前端的图形编程倒也简单，只需要找一个库，多加练习就可以了。练习多了，便发现，需要更多的\u003Cstrong\u003E面向对象编程\u003C\u002Fstrong\u003E经验，要不写出来的代码就跟屎一样。要是在今天，那可能就是\u003Cstrong\u003E函数式编程\u003C\u002Fstrong\u003E经验了。\u003C\u002Fp\u003E\u003Cp\u003E玩了那么多的东西后，我便就对这些东西驾轻就熟了。而在今天看来，仍然走了相当多的弯路。当有人再问我『怎样练习才能成为一个优秀的前端工程师』时，我便想着：我应该好好的回答一下这个问题。\u003C\u002Fp\u003E\u003Ch3\u003EOutput is Input\u003C\u002Fh3\u003E\u003Cp\u003E我一直很喜欢那句，Output is Input 的话，即：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-cc8facd1c49_b.jpg\& data-rawwidth=\&383\& data-rawheight=\&131\& class=\&content_image\& width=\&383\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E即，我们输出知识的时候，便是在输入更完整的知识。因此当我练习的时候，我便会刻意地去结合使用他们，往往能达到事半功倍的效果。想尝试玩一个新的框架时，我便会用这样的逻辑去玩它：\u003Cstrong\u003E使用新框架编写一个应用，再阅读、整理相应的资料\u003C\u002Fstrong\u003E。\u003C\u002Fp\u003E\u003Cp\u003E你若问我，为什么我会这么练习？我想那大概是，我可以\u003Cstrong\u003E更早的得到反馈\u003C\u002Fstrong\u003E。我可以更早的知道，A 框架对于使用过 B 框架的人来说有些难度，我也能轻松地指出他们的差异。甚至，如果这是一个新的项目，那么我还能用一种『不很完美的姿势』完成之。而如果只是完成这个项目，那对于我而言也没有多少\u003Cbr\u003E实质性的提高。\u003C\u002Fp\u003E\u003Cp\u003E遗憾的是对于多数人来说，可能就只是完成项目这一程度，后面仍然还有好长的路要走。做一个好的前端工程师，即要做很多的项目，又要读一些书。即要会使用这个框架，又要知道他的一些基本的思想。\u003C\u002Fp\u003E\u003Cp\u003E习惯了先输出、后输入的过程后，练习起来就很轻松了。\u003C\u002Fp\u003E\u003Ch3\u003E练习框架、技术的时机\u003C\u002Fh3\u003E\u003Cp\u003E练习，那可是相当烧时间的大事；时间，又是一种相宝贵的资源。暂不说，相当于好几年的十万小时理论。对于我们这些每天要早出晚归的工作族来说，八小时以外的时间就更小了。对于一个在校的计算机专业学生来说，也不一定能在四年里搞定。\u003C\u002Fp\u003E\u003Cp\u003E而这时候如果又选择了一个错误的技术栈，哪怕是相当的浪费时间了。好在我们已经在那篇《\u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fread.douban.com\u002Freader\u002Fcolumn\u002F2Fchapter\u002F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E学习前端只需要三个月【框架篇】\u003C\u002Fa\u003E》中讨论了如何选择一个合适的技术栈。此时还有一个问题是，如何在一个合适的时机练习它。\u003C\u002Fp\u003E\u003Cp\u003E过去，习惯了将一些 Idea 放在 \u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fgithub.com\u002Fphodal\u002Fideas\u002Fissues\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003EGitHub\u003C\u002Fa\u003E 上变成一个清单。也因此习惯了，将一些想要玩的框架放到了 TODO Lists 中，再慢慢地享受将他们完结的愉悦感。\u003C\u002Fp\u003E\u003Cp\u003E当有一个新的框架出现时，看看知乎、微博、微信群里的讨论还不错，我就会将这个框架加到 Todo Lists。在一个周末，或者中午，搭建一下项目，玩一下 DEMO。\u003C\u002Fp\u003E\u003Cp\u003E随后，这个框架就会进入评估期。评估一个框架可不是一件容易的事，要从不同的角度去了解它：社区欢迎程度、API 变化程度、Roadmap 计划、Release 情况等等。再确认一下框架是否可以适合当前的项目，可以的话，就会创建一个新的分支来玩玩，又或者直接引入项目。\u003C\u002Fp\u003E\u003Cp\u003E如果这是一个有前景的框架，那么我就会选择一个合适的时机（有时间），创建一个开源来应用它。每个人都会有一些偏爱，这也决定了他们可能不会去玩某些框架，这倒是有些可惜了。\u003C\u002Fp\u003E\u003Cp\u003E当我们决定去练习的时候，我们更需要一些练习的技巧。\u003C\u002Fp\u003E\u003Ch2\u003E练习的过程\u003C\u002Fh2\u003E\u003Ch2\u003E练习框架、技术的技巧\u003C\u002Fh2\u003E\u003Cp\u003E练习嘛，我想就这么几步：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E找到一个模板\u003C\u002Fli\u003E\u003Cli\u003E边修改模板，边查阅资料，以此来完成一个应用\u003C\u002Fli\u003E\u003Cli\u003E阅读官方文档或者代码来补漏\u003C\u002Fli\u003E\u003Cli\u003E编写博客、文章、书籍来加强印象\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E我喜欢的就是这种输入和输出相结合的形式。一开始的时候，就应该先做一个应用。这种用意特别明显，借此可以快速地了解一个框架，就会觉得相当有成就感。随后就是去补缺补漏，以便于我们可以更好地完成应用。最后，当我们写文章去总结的时候，便会对这个框架有更基础的认识——像拥有一张清晰的思维导图，熟悉他的方方面面。\u003C\u002Fp\u003E\u003Ch3\u003E使用模板\u003C\u002Fh3\u003E\u003Cp\u003E对于多数的人而言，也包括我，决定去使用一个框架的时候，表明它已经是一个几近成熟的框架——我们可以很容易找到一些资料。依据现在框架的发展趋势，大部分的框架都会提供一个脚手架，即应用程序模拟。只需要运行这个模板，我们就可以有一个 hello,world。\u003C\u002Fp\u003E\u003Cp\u003E如 Angular 官方提供了一个 \u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fgithub.com\u002Fangular\u002Fangular-seed\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003Eangular-seed\u003C\u002Fa\u003E 的项目，它提供了一套基本的模板，可以用来快速的创建应用。而 React 也提供了一个名为 \u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fgithub.com\u002Ffacebookincubator\u002Fcreate-react-app\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003Ecreate-react-app\u003C\u002Fa\u003E 的工具来快速搭建环境。\u003C\u002Fp\u003E\u003Cp\u003E遗憾的是，大部分的官方 hello,world 都不是很详细，这时候我们可以在 GitHub 上搜索 xxx starter kit 来做同样的事，如 React Starter Kit，就可以轻松地在 GitHub 上找到相就的项目，如\u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fgithub.com\u002Fcoryhouse\u002Freact-slingshot\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003Ereact-slingshot\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-87c416dbbe88d9b38ff359_b.jpg\& data-rawwidth=\&1536\& data-rawheight=\&998\& class=\&origin_image zh-lightbox-thumb\& width=\&1536\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-87c416dbbe88d9b38ff359_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E它提供了一些丰富的组合，如 React、Reactd Router、Redux、Babel、Jest、WebPack 等等的工具。现在，我们在这一步要做的事情就是运行起 hello,world。然后，我们再考虑下一步要做一些什么？\u003C\u002Fp\u003E\u003Ch3\u003E做点什么应用\u003C\u002Fh3\u003E\u003Cp\u003E拿到框架的下一个问题时，我们要去做什么，这个就相当有趣了。挑一个有难度的吧，做不了；挑一个简单的吧，觉得不能练手；还是挑一个实用的吧，比如博客。\u003C\u002Fp\u003E\u003Cp\u003E我写过最多的应用就是与博客相关的应用了。当出现一个新的练手框架时，我总会用这个框架来把博客写一遍。于是，我的博客的后台 API 用 Node.js、Flask、Django 实现过一遍，而前台则用 Backbone、Angular 1、React 实现过一遍，而 APP 方面也使用 Ionic 1 和 React Native 实现过一遍。\u003C\u002Fp\u003E\u003Cp\u003E对于博客而言，我们都很轻松它的功能：列表页、详情页、登录、创建博客等等。我通常只会实现上面的四个基本元素，这和大部分应用的主要模式差不多。对于前端来说，我们会练习到基本的内容：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003EGET 和 POST 数据\u003C\u002Fli\u003E\u003Cli\u003E列表页到详情页的跳转和返回\u003C\u002Fli\u003E\u003Cli\u003E对于用户登录凭据的获取和保存\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E基本上涉及到了一个框架的大部分内容，路由、模板、API 请求、数据存储、用户授权等等。这样一来，我们就要清楚地业务逻辑了，那么剩下的是都是技术的事。\u003C\u002Fp\u003E\u003Ch3\u003E编写一个博客应用\u003C\u002Fh3\u003E\u003Cp\u003E接下来，唯一的问题是：因为对这一系列的技术栈，我们会遇到一系列的困难。当一个新手选择 React 的时候，就会遇到 JSX ES6 Babel Webpack Redux React-Router 等一系列的 React 全家桶。这时，难以下手的主要原因是，不知道这些东西都是干嘛的，也对前端单应用应用没有一个清楚的认识。\u003C\u002Fp\u003E\u003Cp\u003E在没有基础的情况下，直接下手这些会有一定的困难：\u003Cstrong\u003E在学习新的技术栈的同时，也在学习前端应用的组成\u003C\u002Fstrong\u003E。因此：\u003C\u002Fp\u003E\u003Cp\u003E首先，要对前端单页面应用有一个大致的了解。如对于一个前端框架来说， 它要有模板引擎、依赖管理、路由处理、控制器（模板）和状态等等，除此它还需要有构建工具、编译工具、测试框架等等。\u003C\u002Fp\u003E\u003Cp\u003E然后，就需要了解所使用的工具对应的有什么功能。如上面说到的例子里，JSX 相当于是模板引擎、WebPack 是打包工具 \u002F 构建工具、Babel 是 ES6 语言的编译器、Redux 用来做状态管理、React-Router 用来处理路由。\u003C\u002Fp\u003E\u003Cp\u003E最后，需要一个应用的例子来将这些内容串在一起。如当我们打开一个 Web 应用的时候，应该要有一个路由处理的工具，来将用户导向相应的页面。而这个页面会有对应的控制器和模板，路由就是来分发用户的请求。当页面数据数据或者用户操作时，页面上的数据状态就会发生变化，这时就需要状态管理工具来管理。\u003C\u002Fp\u003E\u003Cp\u003E幸运的是，我们已经有了一个 starter kit，在这个 starter kit 中会为我们做好相应的配置。因此，我们可以直接阅读代码来了解它们的关系，逐一的了解他们的功能。过程有点痛苦，结局便是大丰收。\u003C\u002Fp\u003E\u003Cp\u003E这一个过程里，还有一个难点是，我们缺少数据。这时候，我们可以用 moco、MockServer 等工具来做一个假的服务器，以向我们的应用提供数据。\u003C\u002Fp\u003E\u003Ch3\u003E输入和总结\u003C\u002Fh3\u003E\u003Cp\u003E编写应用的时候，我们将一个又一个的内容放到了脑子里，然后发现自己混乱了。需要重新理清他们的关系，这时候可以选择写博客、画思维导图、做分享的形式来整理。\u003C\u002Fp\u003E\u003Cp\u003E当我们向别人讲述一个东西的时候，就不得不压迫自己对此有更深入的了解，要不只能丢脸。这时候，我们又在重新学习这些内容，并且比以往的任何时间更加深入。这也就是为什么我喜欢写作的原因，它能让我的思路更加清晰。\u003Cstrong\u003E原本只是散落在房间里的书籍，现在整整齐齐的排列在了书架上\u003C\u002Fstrong\u003E。在需要的时候，我就可以找到想要的内容。而由于博客的存在，我可以在未来轻松地了解这个框架，别人需要的时候，也可以直接分享相应的经验。\u003C\u002Fp\u003E\u003Cp\u003E等闲了，逛逛官方的文档，还会发现：原来这个地方可以这么用；原来某个地方还可以做得更好。\u003C\u002Fp\u003E\u003Ch2\u003E其它\u003C\u002Fh2\u003E\u003Cp\u003E假如，我们将前端和后台所要求的能力做一些对比，我们会发现前端在高级领域比后台简单一些。我的意思是，前端要在编程方面遇到瓶颈更快，并且需要从其他方面来补充，如后台，又或者是用户体验设计。\u003C\u002Fp\u003E\u003Ch3\u003E关于练手项目\u003C\u002Fh3\u003E\u003Cp\u003E在那一篇《\u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fgithub.com\u002Fphodal\u002Farticles\u002Fissues\u002F19\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E关于编程，你的练习是不是有效的\u003C\u002Fa\u003E》中，我提到，提升技能的项目会有四种：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E纯兴趣驱动的项目。即我的Idea列表上的一个个酷炫的项目，先满足自己再说。\u003C\u002Fli\u003E\u003Cli\u003E理论驱动的项目。这一类的项目会比较少，因为我们需要牵强地驱动出这样的项目，然后以理论的方式驱动它。\u003C\u002Fli\u003E\u003Cli\u003E兴趣结合理论型。有一个长长的Idea列表，难免有些时间会和将要学习的理论有很大的交集。这种的练习效果是最好的。\u003C\u002Fli\u003E\u003Cli\u003E整合成文章、电子书。这一步主要是为了分享、巩固知识点、讨论。\u003C\u002Fli\u003E\u003C\u002Ful\u003E&,&state&:&published&,&sourceUrl&:&&,&pageCommentsCount&:0,&canComment&:false,&snapshotUrl&:&&,&slug&:,&publishedTime&:&T11:08:18+08:00&,&url&:&\u002Fp\u002F&,&title&:&我的职业是前端工程师【六】：前端程序员如何有效地提高自己&,&summary&:&要成为一个优秀的前端工程师，需要什么技能和学习？答案：练习在逛知乎、SegmentFault 又或者是相似的技术社区，我们总会看到类似的问题。新手总会关注于，需要怎样的技能，怎么才能入门？有一点经验的程序员则是，需要练习什么？如若一个程序员已经懂得问…&,&reviewingCommentsCount&:0,&meta&:{&previous&:null,&next&:null},&commentPermission&:&anyone&,&commentsCount&:2,&likesCount&:55},&next&:{&isTitleImageFullScreen&:false,&rating&:&none&,&titleImage&:&https:\u002F\u002Fpic1.zhimg.com\u002F50\u002Fv2-138b5ebba7f2f832bf0f1d10af0dd0a6_xl.jpg&,&links&:{&comments&:&\u002Fapi\u002Fposts\u002F2Fcomments&},&topics&:[{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&前端开发&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&前端工程师&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&程序员&}],&adminClosedComment&:false,&href&:&\u002Fapi\u002Fposts\u002F&,&excerptTitle&:&&,&author&:{&bio&:&待我代码编成，娶你为妻可好 @花仲马&,&isFollowing&:false,&hash&:&fea2f801ab1dc87a87f8bdeb6fdb3394&,&uid&:20,&isOrg&:false,&slug&:&phodal&,&isFollowed&:false,&description&:&工程师 \u002F 咨询师 \u002F 作家 \u002F 设计学徒&,&name&:&phodal&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fphodal&,&avatar&:{&id&:&cebfe26a7aecb4&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},&column&:{&slug&:&beafe&,&name&:&我的职业是前端工程师&},&content&:&\u003Cblockquote\u003E\u003Cp\u003E在过去的几年里，搜索引擎的影响力发生了一些变化——其影响力的趋势是逐渐变弱。应用程序已经变成了流量的一个大入口，当然搜索引擎也还是一个大的入口。搜索引擎优化看上去并没有那么重要，企业靠活动、运营来挖掘新的用户。可当所有的人不重视，而我们重视的时候，那么这个流量入口就是我们的天下。\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cp\u003E自打我开始写博客起（大概是在 2011 年左右），便开始研究搜索引擎优化（Search Engine Optimization）。这项看似不重要的技术，却为我的博客带来 了大量的流量。\u003C\u002Fp\u003E\u003Cp\u003E工作之后，我才发现这是一门大生意——为了排在搜索引擎靠前的位置，每个网站每天都在不断的送钱给 Google、百度、Bing 等搜索引擎公司。当我们在 Google、百度上点击一下，首页上的某个推广链接，可能就会为它们带去几十美刀的收入。要是能竞争到此，那说明这个行业相当的赚钱。同时，处在这个行业的人呐也越来越不赚钱了——他们都把钱交给了科技公司了。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch2\u003E搜索引擎优化都是前端的活\u003C\u002Fh2\u003E\u003Cbr\u003E\u003Cp\u003E如我们在引言里所说的，搜索引擎的流量在逐渐地减弱，但是这\u003Cstrong\u003E几乎\u003C\u002Fstrong\u003E是一种一劳永逸的方式。只需要制定一个合理的 SEO 策略，再瞧瞧看竞争对手的规则、用户的习惯等等。我们就可以坐等：用户从搜索引擎来到我们的网站。随后的日子里，只需要跟踪用户行为的变化，再做出一些适当的改变即可。\u003C\u002Fp\u003E\u003Cp\u003E在决定玩搜索引擎优化之前，我们仍然得判断是不是需要搜索引擎优化。对于那些网站流量依赖于搜索引擎的网站来说，搜索引擎优化必要的，这样的网站有以内容为主的网站，如各种博客、知识问题类网站，网站的主要功能也是搜索的网站，如各种手机、电脑、房产网站等等。而对于大到一定体量的网站——用户已经有这个品牌意识的时候，他们对没有多大必要进行搜索引擎优化，而是更关注于如何提高用户体验。\u003C\u002Fp\u003E\u003Cp\u003E当我们决定为网站进行搜索引擎优先的时候，需要执行一系列相关的调查、设计，并着手开始修改代码，上线，随后再分析线上的情况，不断的改进系统。系统以一种精益的模式在运行着：\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&http:\u002F\u002Fpic4.zhimg.com\u002Fv2-a43e590d08dca1b16f383_b.png\& data-rawwidth=\&220\& data-rawheight=\&229\& class=\&content_image\& width=\&220\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E而完成这部分的主要工作，都是在前端的页面模板上。而在那之前，我们得保证：我们的 Web 应用可以支持后台渲染。\u003C\u002Fp\u003E\u003Cblockquote\u003E\u003Cp\u003E如果当前的单页面应用不支持后台渲染，可以参考我之前写的文章《\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fgithub.com\u002Fphodal\u002Farticles\u002Fissues\u002F20\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E单页面应用后台渲染的三次实践\u003C\u002Fa\u003E》来完善后台渲染的机制。\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cp\u003E作为一个前端工程师，我们需要做一系列的工作：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E设置好 HTML 中的 Title、URL、Keywords、Description\u003C\u002Fli\u003E\u003Cli\u003E页面中的内容是否可以正常显示。如果内容是动态生成的，那么整个系统对于搜索引擎的体验将会特别。尽管 Google 可以动态的渲染页面，但是仍然会有一些影响。\u003C\u002Fli\u003E\u003Cli\u003E页面的内容是否以推荐的 HTML 标签写的。如只有一个 H1 用于作内容的标题，多个 H1 标签可能会造成和 Title 不一致，导致显示在搜索引擎上的结果有误。\u003C\u002Fli\u003E\u003Cli\u003E页面中的内链是否分配得合理。页面中是不是会有指向重要页面的链接，如首页。或者每个分类的详情页都会有链接，并链接到列表页。这样一来，列表页的排名就会比较高。\u003C\u002Fli\u003E\u003Cli\u003E判断页面中的外链是否需要 nofollow 标签。\u003C\u002Fli\u003E\u003Cli\u003E检查页面中的\u003C\u002Fli\u003E\u003Cli\u003E如果有独立的移动站点，要检测一下，是不是需要 rel=\&canonical\& 来表明他们的关系。\u003C\u002Fli\u003E\u003Cli\u003E是否需要采用 rel=\&next\& 和 rel=\&preve\& 来指明页面间的关系，以让第一页拥有较高的排名。同时还能为浏览器开启 Prefetch 功能。\u003C\u002Fli\u003E\u003Cli\u003E等等\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E我们需要做的活有一大堆。不过，考虑到这不是一本详细的 SEO 书籍，我们将关注于基础的部分：设置好 HTML 中的 Title、URL、Keywords、Description。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch2\u003E如何设计一个高质量的 URL\u003C\u002Fh2\u003E\u003Cbr\u003E\u003Cp\u003E今天，很多网站的 URL 的设计都是有问题的。它们看起来一塌糊涂，仿佛是被人洗掉的脏数据一样，没有经过设计，没有经过思考。他们一点都不适合阅读，也不利于搜索引擎优化。\u003C\u002Fp\u003E\u003Cp\u003E刚开始写博客的时候，我从来不会想着去自定义一个 URL。想好一个标题，没有敲好内容就直接提交了，可这个时候生成的 URL 总是很诡异。当我们去设计一个博客的时候，URL 是一个头疼的问题。设计之下，每个人选择的方案都有所不同：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E直接使用博客的 ID，如 \u002Fblog\u002F123，即省事又方便\u003C\u002Fli\u003E\u003Cli\u003E自动生成 URL\u003Cul\u003E\u003Cli\u003E将标题转换为拼音或者英语单词，如 blog\u002Fruhe-sheji-yige-gaozhilang-de-url\u003C\u002Fli\u003E\u003Cli\u003E根据日期和 ID 生成，诸如 blog\u002F\u002F123\u003C\u002Fli\u003E\u003Cli\u003E等等\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003C\u002Fli\u003E\u003Cli\u003E自定义 URL，诸如 blog\u002Fhow-to-design-a-high-quality-url。如果要考虑到一些推荐的 URL 设计原因，如介词，这个 URL 应该变成 howto-design-hight-quality-url。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E也因此，我们会发现大部分的架构设计里，都忽略了对 URL 的设计——只是为了更加方便的使用 RESTful。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch3\u003E受 RESTful API 影响 的 URL 设计\u003C\u002Fh3\u003E\u003Cbr\u003E\u003Cp\u003E依据 RESTful API 原则，我们设计出来的 API 的 URL 都会有这样的缺陷。如下是 RESTful API 设计的一个简单的实例：\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&http:\u002F\u002Fpic3.zhimg.com\u002Fv2-9da254cdb5e7ec6edb2e06_b.png\& data-rawwidth=\&1140\& data-rawheight=\&452\& class=\&origin_image zh-lightbox-thumb\& width=\&1140\& data-original=\&http:\u002F\u002Fpic3.zhimg.com\u002Fv2-9da254cdb5e7ec6edb2e06_r.png\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E可是对于一个博客来说，\u003Cstrong\u003E每个博客的链接都是唯一\u003C\u002Fstrong\u003E的。因此，我们仍然可以使用``where slug=\&how-to-design-a-high-quality-url\&。最后，我们设计出来的文章地址，可能就是 blog\u002F123，又或者是 blog\u002F58c286d7ac502ee。因为，我们是依据这个 ID 到数据库去操作（CRUD）相应的值。ID 本身是自增的，并且是唯一的，所以这种设计因此就比较简单了。因此，我们到数据去查询的时候，我们只需要where id=\&123\&即可。\u003C\u002Fp\u003E\u003Cp\u003E于是，自定义 URL 就是其中的一种形式。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch3\u003E手动自定义 URL\u003C\u002Fh3\u003E\u003Cbr\u003E\u003Cp\u003E与 URL 相比，ID 本身是不如记的。如我的专栏《我的职业是前端工程师》 的豆瓣上的链接是：\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fread.douban.com\u002Fcolumn\u002F2F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E我的职业是前端工程师\u003C\u002Fa\u003E ，而在知乎上则是 \u003Ca href=\&https:\u002F\u002Fzhuanlan.zhihu.com\u002Fbeafe\& class=\&internal\&\u003E我的职业是前端工程师 - 知乎专栏\u003C\u002Fa\u003E。试问一下，如果要记下来的话，哪个更轻松？\u003C\u002Fp\u003E\u003Cp\u003E以我的博客为例，正常的 URL 是这样的，\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fwww.phodal.com\u002Fblog\u002Fuse-jenkinsfile-blue-ocean-visualization-pipeline\u002F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003EJenkins 2.0 里使用 Jenkinsfile 设计更好的 Pipeline\u003C\u002Fa\u003E，对应的标题是：\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fwww.phodal.com\u002Fblog\u002Fuse-jenkinsfile-blue-ocean-visualization-pipeline\u002F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003EJenkins 2.0 里使用 Jenkinsfile 设计更好的 Pipeline\u003C\u002Fa\u003E，这种设计本身可以将关键词融入 URL ，就更容易换得一个好的排名：\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&http:\u002F\u002Fpic4.zhimg.com\u002Fv2-6aedc2dc4aa561dbb988df_b.png\& data-rawwidth=\&1592\& data-rawheight=\&914\& class=\&origin_image zh-lightbox-thumb\& width=\&1592\& data-original=\&http:\u002F\u002Fpic4.zhimg.com\u002Fv2-6aedc2dc4aa561dbb988df_r.png\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E这里的 use-jenkinsfile-blue-ocean-visualization-pipeline 就是优化的部分。而为了设计方便，大部分的博客都会将 URL 设计成 \u002Fblog\u002F123。结果便是，当用户搜索 jenkinsfile 和 pipline 时，就出现了一些劣势。\u003C\u002Fp\u003E\u003Cp\u003E对应的，使用汉字搜索为主的中文网站来说，使用 wo-de-zhiye-shi-qianduan-gongchenshi 可能是一种更不错的选择。我们只需要使用一些分词库，就可以生成对应的中文拼音 URL。\u003C\u002Fp\u003E\u003Cp\u003E当我们有大量的商品的时候，手动定义可能会让人有些厌烦。于是我们应该定义一些规则，然后生成相对应的 URL。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch3\u003E详情页 ：简单的 URL 生成规则\u003C\u002Fh3\u003E\u003Cbr\u003E\u003Cp\u003E考虑到手动生成的难度，以及一些 RESTful 设计的风格问题，我们可以考虑结合他们的形式，诸如：\u003C\u002Fp\u003E动作URL行为GET\u002Fblog\u002F:id\u002F:blog-slug获取某一个具体的文章\u003Cp\u003E是的，只需要改进一下 URL 生成的规则就可以了。StackOverflow 采用的就是这种设计，当我们从 Google 访问一个 URL 的时候，我们访问的地址便是：\u003Cstrong\u003Equestions\u002F:question-id\u002F:question-slug\u003C\u002Fstrong\u003E 这种形式，其中的 id 和 slug 都是自动生成的，如：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cdiv class=\&highlight\&\u003E\u003Cpre\u003E\u003Ccode class=\&language-text\&\u003E\u003Cspan\u003E\u003C\u002Fspan\u003Equestions\u002F2Frest-api-design-getting-a-resource-through-rest-with-different-parameters-but\n\u003C\u002Fcode\u003E\u003C\u002Fpre\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E而当我们使用 question\u002F:question-id 的形式访问时，诸如 questions\u002F，就会被永久重定向到上面的带 slug 的地址。\u003C\u002Fp\u003E\u003Cp\u003E与手动相比，使用这种方式，即可以保证 URL 的质量，又可以减轻后台的负担——我们不根据 URL 来获取数据，我们仍然使用 ID 来获取数据，仍然可以对数据进行缓存。\u003C\u002Fp\u003E\u003Cp\u003E而 RESTful 原则主要解决的问题是：对于资源的分类。，我们就需要一些更高级的 URL 设计。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch3\u003E自动化 URL：分类与多级目录\u003C\u002Fh3\u003E\u003Cbr\u003E\u003Cp\u003E假使我们的网站上拥有大量的商品时，那么我们采用 RESTful 来描述资源时，这个时候路径可能就会变成这样：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cdiv class=\&highlight\&\u003E\u003Cpre\u003E\u003Ccode class=\&language-text\&\u003E\u003Cspan\u003E\u003C\u002Fspan\u003E\u002Fmarkets\u002F3c\u002Fsj\u002Fmeizu\u002Fmeizu-mx5\n\u003C\u002Fcode\u003E\u003C\u002Fpre\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E如果不考虑搜索引擎优化，这个 URL 本身是没有什么毛病的，除了：\u003Cstrong\u003E分类有点多\u003C\u002Fstrong\u003E。\u003C\u002Fp\u003E\u003Cp\u003E分类多对于 SEO 来说，主要问题就是，Page Rank 会被分配到不同的分类上，而导致当前页面的 Page Rank 比较低。因而，对于不同的网站来说可能有不同的策略需求。有的网站可能需要主目录的 Rank 比较高，有的网站则需要详情页的 Rank 值比较高，因此也没有一个好的定论：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E如果希望详情页的 Rank 比较高，那么应该减少分类\u003C\u002Fli\u003E\u003Cli\u003E如果需要分类的 Rank 比较高，那么这样设计就是合理的\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cbr\u003E\u003Ch3\u003E搜索结果页：将参数融入 URL\u003C\u002Fh3\u003E\u003Cbr\u003E\u003Cp\u003E在上面的例子中，因为博客都是唯一的，所以要配置一个唯一的参数都是比较简单的。当我们需要搜索结果时，情况就变得有些复杂——我们需要搜索和过滤。\u003C\u002Fp\u003E\u003Cp\u003E对于一个使用 RESTful API 表示的搜索结果页，我们会这样去配置它的 URL：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cdiv class=\&highlight\&\u003E\u003Cpre\u003E\u003Ccode class=\&language-text\&\u003E\u003Cspan\u003E\u003C\u002Fspan\u003Ehttp:\u002F\u002Fwww.xxx.com\u002Fsearch\u002F?q={keyword}&page={page}&size={size}\n\u003C\u002Fcode\u003E\u003C\u002Fpre\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E然后，再我们的 Link Header 里指定下一页的结果就可以了。这样的 API 设计看上去，非常适合我们的场景。用户在筛选条件里选好想要的条件，再填入关键词就可以了。\u003C\u002Fp\u003E\u003Cp\u003E现在让我们来假设一种用户场景，我们想搜索一个 100~150 元左右的 移动电源，并且它还是深圳产的。这个时候，网页返回的 URL 可能就是：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cdiv class=\&highlight\&\u003E\u003Cpre\u003E\u003Ccode class=\&language-text\&\u003E\u003Cspan\u003E\u003C\u002Fspan\u003Esearch\u002F?minPrice=100&maxPrice=150&product=powerbank&location=shenzhen&page=1\n\u003C\u002Fcode\u003E\u003C\u002Fpre\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E这个时候索引的结果，可就失去了分类的意义了。于是，我们需要一个更好的 URL，诸如：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cdiv class=\&highlight\&\u003E\u003Cpre\u003E\u003Ccode class=\&language-text\&\u003E\u003Cspan\u003E\u003C\u002Fspan\u003Eproduct\u002Fpowerbank\u002F?minPrice=100&maxPrice=150&location=shenzhen&location=shenzhen\n\u003C\u002Fcode\u003E\u003C\u002Fpre\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E那么，对于 URL 索引的 Rank 将会加给 powerbank，点击量 + 页面数量可以让它有一个好的排名：\u003C\u002Fp\u003E\u003Cp\u003E当然诸如淘宝、京东这样的网站就不需要这么做了，他们对于 SEO 的需求没有这么强烈——因为要在百度上排个好名，可不止 SEO 的事了。\u003C\u002Fp\u003E\u003Cp\u003E而如果我们愿意的话，还可以将参数融入到 URL 中，powerbank\u002Frange-100-150-city-shenzhen\u002Fpage-1。这样，不止移动电源上有一个好的排名，100~150 元的移动电源也可以有一个好的排名。这时候，我们需要使用正则来匹配这些规则，一个简单的示例(\\S+)-range-(\\d+)-(\\d+)-city-(\\S+)，匹配结果如下：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cfigure\u003E\u003Cimg src=\&http:\u002F\u002Fpic1.zhimg.com\u002Fv2-e4fa7b9dca40_b.png\& data-rawwidth=\&910\& data-rawheight=\&490\& class=\&origin_image zh-lightbox-thumb\& width=\&910\& data-original=\&http:\u002F\u002Fpic1.zhimg.com\u002Fv2-e4fa7b9dca40_r.png\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E但是，不管怎样这些参数带来的影响，都是相当微弱的。正在要做好的是网站本身，以及相关的站点结构设计、网站内容。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch2\u003E自动生成高质量的站点标题\u003C\u002Fh2\u003E\u003Cbr\u003E\u003Ch3\u003E什么是站点标题？\u003C\u002Fh3\u003E\u003Cbr\u003E\u003Cp\u003E就是我们在搜索结果页看到的那个标题。\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&http:\u002F\u002Fpic2.zhimg.com\u002Fv2-7ee085b9c38fc8397a0fdfd_b.jpg\& data-rawwidth=\&1200\& data-rawheight=\&844\& class=\&origin_image zh-lightbox-thumb\& width=\&1200\& data-original=\&http:\u002F\u002Fpic2.zhimg.com\u002Fv2-7ee085b9c38fc8397a0fdfd_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E如上图所示的结果，是我用 Google 搜索：“程序员如何提高影响力”得到的结果。对应的第一个链接的，如何提高影响力- Phodal | Phodal - A Growth Engineer 就是我博客的站点标题。对应在 HTML 中就是 title 标题：\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&http:\u002F\u002Fpic3.zhimg.com\u002Fv2-269d24c32c71ec9da8d1433ab2daee86_b.png\& data-rawwidth=\&1858\& data-rawheight=\&520\& class=\&origin_image zh-lightbox-thumb\& width=\&1858\& data-original=\&http:\u002F\u002Fpic3.zhimg.com\u002Fv2-269d24c32c71ec9da8d1433ab2daee86_r.png\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Ch3\u003E什么才算一个高质量的站点标题？\u003C\u002Fh3\u003E\u003Cbr\u003E\u003Cp\u003E这是一个很趣的问题。我想应该是在标题里，带有我想要的信息吧。对于一篇博客来说，我可能想看到的内容有：文章的标题，站点的简单介绍，谁的网站等等的内容。\u003C\u002Fp\u003E\u003Cp\u003E如上图中的我的博客的标题，就是一个不错的示例。标题里带有：文章的标题，作者名、站点名、站点简介，即：文章标题 - 作者名 | 站点名 - 站点简介。上图中的 SegmentFault 的标题也相当的不错，文章标题 - 专栏标题 - 站点名。而知乎的专栏，就没有那么有趣了：程序员如何提高影响力2.0 - 知乎专栏。\u003C\u002Fp\u003E\u003Cp\u003E有了上面的例子之后，要完成一个相似的站点标题就更添加容易了：即将产品的相关信息带入到标题里。上面的例子中的 Title 看上去都有点生硬，如果我们愿意的话，我们也可以对其进行优化。\u003C\u002Fp\u003E\u003Cp\u003E该说的我们都说了，最后再来说说为什么吧。如下是 Google 搜索结果中的用户热图：\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&http:\u002F\u002Fpic4.zhimg.com\u002Fv2-25d89bbaa46dfd0e1f655ef_b.jpg\& data-rawwidth=\&1000\& data-rawheight=\&673\& class=\&origin_image zh-lightbox-thumb\& width=\&1000\& data-original=\&http:\u002F\u002Fpic4.zhimg.com\u002Fv2-25d89bbaa46dfd0e1f655ef_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E尽管发生了一些变化，但是我们会发现：用户仍然集中注意力在左侧区域，即文章的标题部分。也就是说，我们应该将标题放在最左边，而与搜索无关的网站信息放在最右边。\u003C\u002Fp\u003E\u003Cp\u003E所以，标题的形式应该是：文章标题 - 各种相关信息。由于 Title 标签拥有比较重要的作用，所以在不影响读者阅读的时候，应该尽可能地把相关的信息放进去。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E欢迎在 GitHub 上为我们提意见：\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fgithub.com\u002Fphodal\u002Ffe\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003Ephodal\u002Ffe\u003C\u002Fa\u003E\u003C\u002Fp\u003E&,&state&:&published&,&sourceUrl&:&&,&pageCommentsCount&:0,&canComment&:false,&snapshotUrl&:&&,&slug&:,&publishedTime&:&T11:29:38+08:00&,&url&:&\u002Fp\u002F&,&title&:&我的职业是前端工程师【八】：SEO 技巧，如何设计一个高质量的 URL 和标题&,&summary&:&在过去的几年里，搜索引擎的影响力发生了一些变化——其影响力的趋势是逐渐变弱。应用程序已经变成了流量的一个大入口，当然搜索引擎也还是一个大的入口。搜索引擎优化看上去并没有那么重要，企业靠活动、运营来挖掘新的用户。可当所有的人不重视，而我们重…&,&reviewingCommentsCount&:0,&meta&:{&previous&:null,&next&:null},&commentPermission&:&anyone&,&commentsCount&:8,&likesCount&:70}},&annotationDetail&:null,&commentsCount&:24,&likesCount&:153,&FULLINFO&:true}},&User&:{&phodal&:{&isFollowed&:false,&name&:&phodal&,&headline&:&工程师 \u002F 咨询师 \u002F 作家 \u002F 设计学徒&,&avatarUrl&:&https:\u002F\u002Fpic2.zhimg.com\u002Fcebfe26a7aecb4_s.jpg&,&isFollowing&:false,&type&:&people&,&slug&:&phodal&,&bio&:&待我代码编成，娶你为妻可好 @花仲马&,&hash&:&fea2f801ab1dc87a87f8bdeb6fdb3394&,&uid&:20,&isOrg&:false,&description&:&工程师 \u002F 咨询师 \u002F 作家 \u002F 设计学徒&,&badge&:{&identity&:null,&bestAnswerer&:{&topics&:[{&type&:&topic&,&id&:&&,&name&:&编程&},{&type&:&topic&,&id&:&&,&name&:&程序员&}],&description&:&优秀回答者&}},&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fphodal&,&avatar&:{&id&:&cebfe26a7aecb4&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false}},&Comment&:{},&favlists&:{}},&me&:{},&global&:{&experimentFeatures&:{&ge3&:&ge3_9&,&ge2&:&ge2_1&,&growthSearch&:&s2&,&nwebQAGrowth&:&experiment&,&qawebRelatedReadingsContentControl&:&close&,&liveStore&:&ls_a2_b2_c1_f2&,&qawebThumbnailAbtest&:&new&,&nwebSearch&:&nweb_search_heifetz&,&rt&:&y&,&showVideoUploadAttention&:&true&,&isOffice&:&false&,&enableTtsPlay&:&post&,&editorVideomakerEntrance&:&e&,&enableVoteDownReasonMenu&:&enable&,&newLiveFeedMediacard&:&new&,&newMobileAppHeader&:&true&,&androidPassThroughPush&:&all&,&hybridZhmoreVideo&:&no&,&nwebGrowthPeople&:&default&,&nwebSearchSuggest&:&default&,&qrcodeLogin&:&qrcode&,&seE&:&1&,&isf8&:&1&,&isShowUnicomFreeEntry&:&unicom_free_entry_off&,&newMobileColumnAppheader&:&new_header&,&feedHybridTopicRecomButtonIcon&:&yes&,&androidDbRecommendAction&:&open&,&zcmLighting&:&zcm&,&androidDbFeedHashTagStyle&:&button&,&appStoreRateDialog&:&close&,&default&:&None&,&isNewNotiPanel&:&no&,&wechatShareModal&:&wechat_share_modal_show&,&growthBanner&:&default&,&androidProfilePanel&:&panel_b&}},&columns&:{&next&:{},&beafe&:{&following&:false,&canManage&:false,&href&:&\u002Fapi\u002Fcolumns\u002Fbeafe&,&name&:&我的职业是前端工程师&,&creator&:{&slug&:&phodal&},&url&:&\u002Fbeafe&,&slug&:&beafe&,&avatar&:{&id&:&v2-54f861c7e0d899bf5744bda5bce1b171&,&template&:&https:\u002F\u002Fpic4.zhimg.com\u002F{id}_{size}.jpg&}}},&columnPosts&:{},&columnSettings&:{&colomnAuthor&:[],&uploadAvatarDetails&:&&,&contributeRequests&:[],&contributeRequestsTotalCount&:0,&inviteAuthor&:&&},&postComments&:{},&postReviewComments&:{&comments&:[],&newComments&:[],&hasMore&:true},&favlistsByUser&:{},&favlistRelations&:{},&promotions&:{},&switches&:{&couldSetPoster&:false},&draft&:{&titleImage&:&&,&titleImageSize&:{},&isTitleImageFullScreen&:false,&canTitleImageFullScreen&:false,&title&:&&,&titleImageUploading&:false,&error&:&&,&content&:&&,&draftLoading&:false,&globalLoading&:false,&pendingVideo&:{&resource&:null,&error&:null}},&drafts&:{&draftsList&:[],&next&:{}},&config&:{&userNotBindPhoneTipString&:{}},&recommendPosts&:{&articleRecommendations&:[],&columnRecommendations&:[]},&env&:{&edition&:{&baidu&:false,&yidianzixun&:false,&qqnews&:false},&isAppView&:false,&appViewConfig&:{&content_padding_top&:128,&content_padding_bottom&:56,&content_padding_left&:16,&content_padding_right&:16,&title_font_size&:22,&body_font_size&:16,&is_dark_theme&:false,&can_auto_load_image&:true,&app_info&:&OS=iOS&},&isApp&:false,&userAgent&:{&ua&:&Mozilla\u002F5.0 (compatible, MSIE 11, Windows NT 6.3; Trident\u002F7.0; rv:11.0) like Gecko&,&browser&:{&name&:&IE&,&version&:&11&,&major&:&11&},&engine&:{&version&:&7.0&,&name&:&Trident&},&os&:{&name&:&Windows&,&version&:&8.1&},&device&:{},&cpu&:{}}},&message&:{&newCount&:0},&pushNotification&:{&newCount&:0}}