以下文章仅针对自己的博客形态进行分析。
目的——写技术博客是为了什么
①对感兴趣的知识进行梳理总结形成系统。
②需要讨论的氛围，希望别人能指出博客中的问题，发现更优解，或有更好的idea。
③建立一个查询备忘录，避免再次遇到该问题从头来过，这方面的博客往往需要更新很频繁，不断地有新东西增添进入。比如mac的操作困惑。
博客类别
博客大概分为两部分。
一是边学边记型笔记。修改相当频繁，学到什么往里面加入相关内容。笔记内容可能是零散的，仅做了表面的大致分段，不一定系统，当然可以后期进行整理。针对的领域也比较具体。
二是系统的博客。学习路径可能有两种：①可能是对某一个主题非常感兴趣，进行Syntopical reading，搜集相关资料然后针对这个特定的主题写博客。比如：正则表达式在项目中经常卡我，写的太慢，运用不熟练影响编码效率。于是就产生了兴趣，想要系统梳理它，把它研究透彻，下次再写提高工作效率。②也可能是针对某个阶段、某项目某件事进行回顾性质的反思总结，比如xxx产品总结、项目总结、自我认知类型的思辨总结。
简书写技术博客不是最佳实践
频繁添加内容不便
博客是一种对于所学所知的记录方式，而学习是需要更新的，所以博客面临回看更新也是很普遍。当然有那种精品博客，一般是知识体系成熟的作者做的，介绍的知识也比较系统、全面、有深度。一旦在某某平台发布基本也不会面临频繁修改的问题。这里只谈笔者自身的博客的特点。
markdown的初始目的也是为了去快速地表达给对方看，方便的是写作者本身，解放他们对于样式的操作（直接用特殊符号来实现优雅的样式使得操作脱离鼠标）。但当博客属于边学边记型类型的笔记时，markdown这种方式带来很大的不便利。因为修改是相当频繁的，当看到一堆##符号的时候，只会眼花缭乱。
没有目录树结构——不便于多子主题文章的查询
一旦一篇文章的分主题比较多，在阅读时对于思维上构建整体文章的结构就会比较费劲。
BTW，对于一个文集来讲，也应该搭建起一个系统的结构，比如前端开发这文集，里面的知识如何能通过标签分类、目录树、思维导图搭建，建构起系统来。在一个文集内每篇文章与每篇文章也是有关系的，也是可以归类
文章无法归类——不便于形成系统的知识体系
文集内部的文章相互之间都是有关联的，可能是包含关系，可能是有交集。比如我可能写了一篇数组，它属于es6领域。而现在所有的文集都flatten成同一级没有一点层次结构可言。
没有跨文集查找功能
尤其在有相似性的文集间会存在这个问题。比如我有两个文集一个是前端开发基础文集，一个是前端开发进阶文集，这两篇都有可能写过正则的一些东西。现在学到了关于RegExp的exec方法中g标识的新知识，想加到旧有的博客中去。产生搜索不方便。【想办法归纳总结、合并解决该问题】
没有快捷键
我想调换标题顺序，就不能⌘+shift+⬆︎上下调动
类似于[]()这种东西
简书不适合做回顾性的学习笔记
从它的收藏功能就可以看出来了，没有分类，没有tag功能，没有搜索。它的产品设置初衷就是让你不断地去挖掘新文章，而不是逮着一个收藏的文章反复看。
简书适合做什么
简书适合于阅读。当个阅读平台很不错。
简书适合纯粹的自我思想表达。所写内容、所写主题的资料全部已经存放在脑海里，不需要去外界资料的。这样就不需要来回切换页签去查资料，可以一直专注在写作、表达本身。比如：梳理自我认知、对发生的一件事情写一篇评论的随笔。当专注在写作上时，markdown的优势也就体现出来了。
对所做过的项目进行总结也不是全适合，比如项目管理、人员安排、任务分工方面的经验就选择简书挺好，因为这些事情已经发生完了，已经在脑海里，不需要额外查阅资料了。如果是技术细节代码细节的总结，就总是得翻看源码。
自己存在的问题
同时补充多篇博客的坏毛病。写一篇博客的过程中会去查资料，查资料的时候又会发现其他的问题，然后又去查支线的资料，结果支线的资料也想记录，于是就会跳出这篇博客。来回切换博客页面（又涉及全屏等操作）太浪费时间！！
