2018年2月9日
从开始到最后大概写了一个月左右（中间有半个月要上考研班）。
基本上从头踩坑踩到尾
前端方面用了materialize、vue、jQuery
其中materialize更多是样式，对着文档搞没什么问题
之所以混用jQuery和vue是因为有些页面没必要用vue，但是又有一些小地方需要动态控制。
因此个别页面用到了jQuery
比如被我用来当作标签的

<div class="chip" v-bind:class="tag[4]">
	<img v-bind:src="tag[3]" onerror='$(this).attr("style","display:none")' onload='$(this).attr("style","")' />
	<span v-text='tag[0]'></span>
</div>

这里由于不确定图片是否有效，采用这种js判断的方式来保证看上去不那么难看（其实不是必须要到jQuery）

vue方面遇到的主要的坑就是，它的绑定(v-model)是异步的，可以理解成虽然他是双向绑定，但是其实是有一个延迟的。大部分情况下其实没有什么问题。但是如果我在js里修改变量值，然后立即提交表单，表单里的值其实还是没有变化的。因此需要一个回调函数来确保同步之后再继续下面的步骤。这里的Materialize.updateTextFields();则是materialize里的更新表单动画的函数

vue.$nextTick(function() {
	Materialize.updateTextFields();
	vue.loading = false;
});

后端方面遇到坑比较多，不过大部分还是在写一些很没意思、重复性的工作。
前期架构没有想太透彻就开始着手去做，导致后面有大量的返工。
按照构想，主要分成3层：路由层、前端、后端。其中数据库则在后端的底层。
后端从数据库拿到需要的数据，处理完输出到/api/xxxx，然后前端通过fetch来获取需要的数据。然后屈服于seo优化，页面部分就直接用jinjia渲染了，只在那些涉及到搜索的页面使用了这个思路。

花费了大量时间在上下文上。
一般flask里常用的上下文是g，session,cookie
其中，session是加密的cookie。
g存在于单个请求。从before_request到after_request都是它的生存周期，但是这个请求结束后，他就被销毁掉了。也就是说，同一个用户，开两个网页时对应的两个g是相互独立的。
而session(cookie)则是存在用户电脑上的（貌似别的框架里，session在服务器，用户存的是session_id）。这也就是说，我们可以用session来判断用户身份，毕竟http没法记录用户状态。但是session和cookie是有大小限制的，因此有很多想法其实是没法实现的。
比如我曾经想在所有的before_request记录用户访问的url，然后存到session或者cookie里，用于去重的访客统计，然后就超出空间大小了……

至于一些写法上的问题，前期没有注意，导致函数名不是很规范，同时一开始为了清晰，把get和set功能分开放在两个文件夹，然而这在后面调用的时候更麻烦。
对于同一个内容，合在一起其实更方面，他们他们有大量的相互嵌套调用。

另外，数据库方面使用sqlite3。为了方便别的地方调用，把常用的select、insert、update、delete抽象出来，把所需的参数按照字典的形式传过去，然后拼接成语句。

搜索方面使用了jieba分词，先把整篇文章分成词语，然后统计词频，鉴于这个过程很慢，统计完后直接存在数据库里。

markdown转义参考了segmentfault的markdown转义。
不过看了一半就自己瞎写了
整体还是能跑起来的，嵌套以及一些不规范的语法也都能正确转义，但是在一些奇怪的地方可能会有bug。
目前还在测试中。
最大的体会，大概是：不要想着修bug，不影响用就行了，先上线再慢慢修吧。反正永远也修不完……