方案 2 挺好的鸭~开发时用一套密钥，生产时用另一套，生产环境密钥不给开发就好了。

没毛病，1 楼靠谱

方便直接上代码么 关键字段脱个敏啥的 你现在说的完全没法定位问题= =

查完了分享一下内存泄露的原因呗~

千万级只要索引建得合理也是妥妥的，用在 oltp 业务上都没啥问题，更合况你这听起来更像是 olap 业务，如果确实是 olap （比如制卡商一天查一次，不需要实时），那就更容易了，每天在旧表跑一遍过滤出结果放新表里，让查询请求查新表。

这个数据对于商业数据库来说真不算什么，你要不先用直接的思路试试，看看能不能达到要求，如果不能把问题说一下（比如用了 10 秒，你希望 1 秒以内，或者机器查不出来内存爆了之类的），具体的操作说一下（比如表的 schema，查询使用的 sql ）大家才好帮你研究瓶颈在哪以及解决方案。

牛逼！

不用管它，py 这种语言 linter 能发挥的功能很有限，写几个 meta class 的它就看不懂了。
就 lz 的这个例子，也不一定说你写的这个就完全没问题，万一
t = False
#...(好多 code)...
del t
#...(好多 code)...
#...(好多 code，然后你忘了你已经 del 了)...
ss()
你猜结果会是什么样？

@sunjourney
“如果 layout 不对就返回原值”这句是有问题的，按照这个接口设计的含义 layout 只要是个字符串，就不可能“不对”，而且也不是返回原值，这里的 format 函数要理解为一个能够格式化时间对象的通用字符串格式化函数（想象一下 c 里面的 printf ），而不是一个把时间对象进行格式化的函数。
当然，作为 Time 的成员函数这么设计我觉得确实是有一点 confusing 的。

我去年做过一套类似的东西，我们的场景是有很多种不同的业务类型(workflow)，各种业务的流程(step)不同，但是固定不变的，比如：
业务 1：先做流程 A，再做流程 B，最后做流程 C
业务 2：先做流程 W，再做流程 X，再做流程 Y，最后做流程 Z
其中每个流程都有一个结果状态，进而还支持一些简单的分支，比如：
业务 3：先做流程 A，若 A 成功（成功即一种结果状态）则做流程 B，否则做流程 C

上面说到，我们每种业务具体的流程是不变的，所以业务 x 的具体流程(workflow 由哪些 step 构成)我们写进了代码逻辑里，然后就有一个核心的函数 next_step 来实现业务流程的决策，大概就是
next_step(workflow_category, prev_step)

然后其实要拓展到完全自由的流程也挺方便，把下一步要做什么流程写进上一步流程的一个字段里就行。

那就这么搞就行啦：
[darshboard(x, y) for x in namepool for y in typepool]
如果你要组合的参数列表更多，或者甚至是不确定的数量，那就可以去研究研究 6 楼说的那俩函数。

还是再整理一下问题描述吧
前面说 dashboard 的参数是*两个不同长度的列表* 那不就直接把两个 pool 传进去不就行了吗？毕竟那两个 pool 不就是*两个不同长度的列表*吗？
后面的 dashboard[clienta,type1]这都不知道是啥了，也许是想说 dashboard(clienta,type)？如果是的话那不就和“ dashboard 的参数是两个不同长度的列表”矛盾了吗？

因为确实不会有 error，layout 参数里就是什么都可以传……

似乎不支持 py3 啊 骚微有点尴尬

来个另类的吧 gitbash

@nezumi85757 你说得也有道理 还确实没注意到常用的移动端软件的和桌面的 qq 这种“小竖条”型的设计思路有一定类似…… ins 大概是打开的时候才对桌面 /移动端进行判断吧

快跑！（开个玩笑……