@workwonder 我也知道 Django 可以用迭代器模式遍历 queryset，这样能大大优化内存占用。但我觉得这有点自欺欺人(减少单次请求的内存消耗，并没有实际解决内存的不释放问题，顶多是缓兵之计)，而且我是配合 drf 使用，改成迭代器模式不太自然。

@janxin 我那个 Django 应用的并发量和日访问量都很小，问题是数据量很大，经常是上万条记录(再加上关联查询)一起 load 到前端，实际上一两次这样的请求消耗的内存总量并不大，要命的是内存不及时释放(或者根本不释放)，持续上涨一直到爆。

@chenqh 我刚举的例子，Django 项目没用 celery，flask 项目配合 celery 使用的。
多谢你的设置指示！

@lilydjwg 我的 Python 程序都是靠自杀+接力来实现长期运行的，搞不搞笑，我觉得很羞辱，曾经拒绝启用这样的参数（比如 gunicorn 或 uwsgi 里面），后来不得不妥协了。

@lilydjwg 有没有关于此方面讲的比较透测的资料。
关于版本，我用 python 3.5 感觉泄露问题还很严重啊。

@lilydjwg 根据普遍的反映，Python 在内存方面并不省心。 据说 Python 程序一旦在某个时刻占用了很高的内存，后面就下不来了。而我的多次实践也未能幸免于此，我的 Django 应用不得不启用 max-requests + max-memory 来不断采用新的 worker 来轮回，另一个 flask 应用里面的 celery workers 也不得不根据消费的任务数量来自杀轮回。关于此大神能否谈谈看法？
可以试试关键词 python memory leak not release 看看相关材料。

https://gist.github.com/wonderbeyond/1806c7b43d3e642e5ad0aee7052b8e8f

这是我记的笔记，搬 Django 的实现，为什么写这么复杂，大家可以发表下看法。

atom 前不久在性能方面有巨大改进，可以再试试。

@alwayshere 全部开源做不到，但你这样掩藏前端代码太刻意了，不值得花那个时间。

代码不被复用还有价值可言吗

坚持几天习惯了就是自然而然的事情了

有

@a87150 这里 star 数量跟流行度不成正比，比如 python 很晚才放到 github 的，没机会 star 啊。

我也是实现成自动续期了。实际的有效期比较短，但是服务器每次见到 token 发来，都会自动续满。

不知这样安全性如何?

我不喜欢使用自动格式化，写的时候自然遵循风格规范，不就行了，自动格式化有时候没有手排的漂亮。

没人像我一样使用 insomnia 制作一份 API 调用示例导出给对接者直接调教吗？
https://insomnia.rest

atom 开发团队还在拥抱 coffee，真担心这个会影响 atom 的发展。

混乱

@est 片面了
越是流行的项目越是 issue 堆积严重，人多想法和意见也多。