总的来说，还是推荐 Flask 。 Flask 本身的文档简洁明了；框架结构更开放； sqlalchemy 既可以写对象映射的语句，也可写 sql 原生语句；有一本 Flask web 的中文经典教程，质量非常高；现在重要的库都支持 Python3 。
如果只是做个官网，或者现在很常见的 APP 下载单页站， Flask/django 那个熟选哪个，没什么区别，如果未来是做新闻内容类型的网站， django 也没什么问题，但是如果业务逻辑定制度很高， Flask 处理起来，会更简洁明了；这方面 django 用不上的功能可能比用的上的模块要多多。

@sfree2005 看起来你这个“粗暴”的方法是很实用的，哈哈。是分库分表的思路啊。其实 Article 表里就是内容 content （ text 类型）占空间，其他的字段全部导到内存里也没多大。

@daybyday 谢谢！负载过重的话，这是个可行的方式

yield_per 倒是一个看起来可以平衡内存占用和 SQL 查询效率的一个方式，以前没有用过，可以尝试下实际的运行效率好不好。

@NearTan "SQLAlchemy 层"，你是指用 ORM 的 xxx.query.filter(www.query.filter(www.query.filter()))这样的嵌套查询吗？

@ChiChou @NearTan 主要是因为要把这些 Articles 先全部取出来，再根据 author/ip/post_time 等等做多重运算后，再 remove 一些数据。分页只能放在最后呈现的阶段啊。（当然，也可以把这些多重运算，在数据库中用 SQL 语言先解决，这个就是前面提到的，担心复杂的 sql 语句效率的问题）

@loading 嗯，一般情况下这个必须是值得的。就是遇到 Article 这种对象，有文章的内容（ text 类型），可能一篇文章记录就几十 K 啊。比如查询出来用户关注的文章， 1 个用户关注 1000 个人，想象下 1 万个用户，那内存得要多大啊？

@Infernalzero 尼玛，轻松就显出大神本色啦。。。我怎么就一直想着从环境、和配置文件方面去解决，没想到 ip 本身来判断呢，难怪大牛脑容量不一样 ^_^

@fengyqf @Midnight @holyzhou @just4test @Infernalzero 谢谢大家的建议~ 是因为访问 ip 要参与后面业务逻辑的运算，判空后面就跑不通了。

@Midnight 嗯，是的。生产环境（ nginx + wsgi + app ）的 wsgi 环境也是单独配的，和开发环境都不一样。开发环境除了数据库和 git 本地配一下，其他基本上用 IDE 就完成了。

@Infernalzero 生产环境中优先取的是 X-Real-IP ，这个在开发环境（开发人员有的 Mac ，有的 Win ，有的 Ubuntu ，全部配成 linux 的生产环境一模一样，很费劲...）中没有，会报错。为了保持业务逻辑可以正常跑，开发环境就只能改回 remote_addr 。
虽然手工改几行代码不是很麻烦，只是每次部署都要重复改这几行也头大。。。

@sunchen 就是啥都不要啦，也要力保 users 表嘛 *_*

@mashpolo @elgoog1970 @Neveroldmilk 谢谢，用系统命令行可以操作啦 (*_*)

谢谢 @ipconfiger @pynix @loading 的建议 -:)

谢谢大家的建议，试了不行，我再看下返回的结果是什么格式的值

@julyclyde 看了一下 Gunicorn 的核心开发者 Starefossen 今年 5 月做了这样一个说明：
#633 removed functionality which made Gunicron update REMOTE_ADDR to what a trusted upstream client sent in the X-Forwared-For header. This was a violation of RFC 3875 CGI Version 1.1 which states the following:

4.1.8. REMOTE_ADDR

The REMOTE_ADDR variable MUST be set to the network address of the
client sending the request to the server.

Because of this change, if your Gunicorn server is behind any proxy you will only get the proxy's IP address as the REMOTE_ADDR.

I think there should be some sort of mention of this pitfall in the documentation along with a suggested good workaround (if there exists any). I'll see if I get the time to submit a PR at the end of this weekend.

===========
应用程序是不能通过 Gunicorn （版本阶段应该是 Guniconr19.0+吧）来取 REMOTE_ADDR 了（这个值是空的），而 X-forwarded_for 的 client ip 值容易被修改和伪造（实际测试中发现，通过微信内置浏览器访问的话，这个值会取不到）。

一次性交付的项目，基本不考虑后期迭代升级，而自身有有丰富的 2.7 经验，自然选择 Python2.7 。
通常而言，项目都是需要不断更新的， Python3+推出其实已经快 8 年了，重要、常用库基本都更新支持了，建议选 Python3.5 。

@xiangace 兄弟，你试过这样能生效吗？怎么我用你说的方法，不行啊...
我原来的写法是：
from flask import request
def get_real_ip():
ip = request.remote_addr
这样直接用 Flask 自带的 wsgi 跑，或用 Gunicorn 跑 mydomain.com:80 端口，都是可以成功获取用户真实 ip 的，但 Gunicorn 前面再套一层 nginx 就不行的。