你这个纯文字完全感受不到啊，随便找个图床把照片传上去，然后把链接发出来啊，比如如 chrome 的插件微博是个好图床，又比如说 imgur.com, sm.ms 等等…

@ykjsw win chrome 下测试了下，这个页面的编辑体验好差啊，而且也不满足我上面需要分享的功能吧，如果要放在 github 上的话，我直接就用 gist 啦，不过还是谢谢啦。

@VeeSong 多谢， evernote 网页版 + Markdown here 插件 这个挺赞的，就是 evernote 的网页版本编辑体验太差，而且有些输入会被 ervernote 预先格式化掉，导致最终的结果有时候会不太对

@kozora 哈哈，好，等等看啦

@kozora 昨天后来恢复了，官方反馈是宿主机宕机了，不过也没讲任何赔偿的事情啥的 =。=

@chousb 工单已经提了，现在恢复了，只是过来问问看有没人也遇到相同情况的

@Parabolazz 嗯，我的截图就是作业部落的 =。=

@shulen 如果没有我题述的问题的话，我也愿意一直用啊

@sansansi 有道云笔记测试下了，效果确实不错也能分享，不过好像没有私密分享(有密码之类的），另外好像没有版本管理？也不支持阅读者评论？ （这些都是作业部落支持的）

@zzzhan 但是这个还是只能当客户端用吧，本身不带存储，想分享的时候比较麻烦？

@workwonder #打头的代码行前后多了空行，如果你试下连续多行#的注释，就知道这个的效果有多差了

@timothyye @mogging 题目说了我也一直在用作业部落啊，如果这个渲染效果改好了，我也愿意继续用啊

@stcasshern 谢谢，我试试这个

@hyrijk 笔记还坚守在 evernote 上，我看看有道云笔记吧，谢谢

@beginor 用 gitlab 的话，我还不如直接用 github 的 gist 吧， 2333

@paulw54jrn 谢谢

stackedit.io 我一直在用，但是如题目所述，在渲染上有点小问题

https://jbt.github.io/markdown-editor 的这个在渲染代码时的对齐的时候有问题

http://markdownlivepreview.com/ 对代码的高亮支持好像有问题

**而且后两个很明显在分享上不满足要求啊**

@erDaren 实测了下，马克飞象下，同样的 markdown 代码渲染也是有问题的，看来是某个引擎的问题吧。

@Phant0m 这个也只能做客户端用吧?

@paulw54jrn 这个如果要分享渲染后的页面好像比较麻烦？ 另外，这个页面里面对代码渲染的效果感觉稍微有点不喜欢

@twistoy 我看看 gitbook ，应该可以用，我研究看看

@erDaren 满足功能的话，付费是 OK 的，印象笔记的话国内版本现在的分享几乎废了吧，国际版速度有点堪忧啊

@16500682 放在 github 的私有项目的话，好像分享比较烦？ gist 倒是可以，但是觉得管理上有点乱，所以不太想用， coding 的我试试看吧，谢谢

@blanu @zhenjiachen @moe3000 vsCode 和 ace 编辑器都是客户端吧？ 客户端的话，我现在比较倾向与用 atom ，或者 vim+markdown preview ，但是想分享给别人渲染后的页面时，比较麻烦。

@beyond_st 如果作业部落的渲染改好的话，我还是很喜欢用的，之前已经买了会员了 =。=

@jasoncraft 如题所述，我现在就是用作业部落的，但是在渲染上有点问题

@georgema1982 果然我看文档不够仔细， contenttype framework 确实是个很好的解决方案，多谢，多谢

@cielpy 多谢，这个有用。

@cielpy 你好，麻烦问下你的博客配置里面对自己的 sshkey 私钥做了加密，那个地方具体是怎么实现的？ 谢谢

@jinxueliu 不用， smba 可以把自己电脑的一个文件夹共享出来的，然后告诉别人地址就好了，和 win 下的共享是一样的， nginx ， ftp 的话也可以自己搭，其实还有一个选择可以用坚果云的团队版，不过需要付费就是了。

@zrp1994 @jinxueliu 这种+ssh pubkey 的方法等于要求对方把自己电脑账户共享给你了，明显不合适啊，建议要么开一个账户专门用于文件共享，否则的话还是用匿名的 ftp ， nginx ， 或者 samba 吧， 用 smaba 的话还可以跨平台呢 =。=

从贴出来的代码猜测应该是想在 workqtree 或者 readcachetree 占用 cache 超过一半的时候将数据写回并清理缓存吧。

@domty 这个 json 方案我也考虑过，但是如果出现过滤条件在 json 序列化的部分会比较难处理… 其实用 2 让我觉得最不爽的就是感觉表很零散，没有很好的办法来处理，感觉很失控，没有一个地方可以查出来现在都有那些 map 表之类的数据(从数据的 meta 数据查我觉得也不是很好的方案）。

谢谢你的建议，我现在感觉如果最终的 BCD 表的数量不是很多的情况，可能用 1 还会是一个不错的方案？ 你说的查询糟糕是指性能上还是说代码写法上比较糟糕？