现在回去做高考题，未必做的过高三学生啊。对自己工作经验有信心的，一般直接带自己编写的代码，去给面试人员讲就好了。面试官听不懂，说明也没必要去了；能听懂自然会认可你的经验价值。

想象中，如果在初学阶段，有个技术大牛能够随时请教，呼之即来，来之能问，问之能 Done ！当然是个快速进步的好办法，不用把无数的青春耗在 debug 上，有时候连 debug 的方向都是错的，这个时候有人指点一下，必然节省很多时间。

为什么没有这样的人呢？最根本的原因是经济上的。这样的牛人老师随时 stand by ，你一般人要么付不起一对一老师的薪资，要么付得起也觉得不合算。如果是按 Q&A 的数量来计费，更加无法衡量价值，因为一个问题的解决难度，从来就没有准确的衡量方法，你这个红包该包多少呢？

回到现实，技术晋级普遍的方式，大概也就是自学+项目操练+网络交流，这样的路径了吧。

总的来说，还是推荐 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 。