J_hao104

图片不是传到服务器上的，是传到七牛云或者其他地方，写外链地址就行了。

支持啊 列表页 http://www.spiderpy.cn/blog/list/

@zhoujiaguang 那一步哪一条命令出的这个错

确实是，原来的网站挂掉了，过两天换一个

Django1.10以上要这样： ``` python manage.py makemigrations blog python manage.py migrate ``` 先makemigrations app名字，会在app对应的文件夹下生成migrations文件夹包含迁移的sql语句 然后在执行migrate自动创建表

之前工作时整理过一份 1、原开发模式： 采集平台原开发模式是通过Template渲染的方式(MVC模式)。浏览器把请求交给Django处理，Django根据视图函数，读写数据或做些处理操作，最后通过Template渲染成html页面返回给浏览器。处理流程图：  2、前后端分离开发： 后端只需要提供api接口，前端通过异步方式调用api获取数据。这样后端负责数据处理，前后只负责展现。大致流程类似这样:  3、为何选择前后端分离： 台采用未分离的开发模式，前后端代码混杂在一起，这种MVC架构就决定了前端需要高度依赖后端。 当时为了协作开发，当时提出了两种方案: （1）依然使用不分离的模式：前端写好静态demo，后端翻译成Template模板。这样后端人员会重复工作； （2）采用分离的方式: 后端重构原有代码只提供RESTful接口，由前端负责展现。 后来商量确定了采用第二种方案。 4、分离后的优缺点: 分离前： 前后端混杂：前后端职责不清楚，前端代码以Template形式由后端维护，代码混杂在一起。这样代码修改更新都非常麻烦。再加上采集平台业务逻辑比较复杂，久而久之，代码的维护性就极差； 开发效率：如果前端不熟悉模板语言，还需要将前端代码翻译成Template。 多人协作: Django的Template高度依赖Views，不适合多人协作开发模式。 分离后： 服务器压力：后端只需要返回json数据，页面渲染、数据验证、处理等均可以在前端完成。这样可以将服务端的压力减少到最小，给用户更流畅的体验； 开发效率: 分离后，后端只需要专心于业务逻辑层的开发；而前端只需要关注数据展现； 多人协作: 前后端分离开发后，只要前后端人员约定好所有api数据传输格式后，便可以各自自行开发，互不影响； 前端发挥局限性： 前端脱离后端约束，可以更加专注页面美化，增加用户体验。 工作量: 分离后后端只需提供数据api不用关心模板渲染，工作量有所减少；但是相反这样前端的工作量会有增加。而且这种开发模式需要花大量的时间在联调和沟通环节，bug修复也比以前困难。

@cgDeepLearn 对的

http://你的域名/blog/get_comment/

和markdown语法一致的 , 像这样 ```python print("hello") ```

/blog/get_comment/ 这个接口就是