其实有个 https://github.com/corpnewt/gibMacOS 实现了类似功能...

可以考虑匿名内部类引用外部类属性的场景。虽然 lambda 和匿名内部类不一样，lambda 是一个闭包，但这不影响引用外部属性的这个场景。

这个引用会让该属性必须使用 final 修饰，因为防止你在闭包内进行修改。同理，你对集合进行修改，需要考虑线程安全问题（也就是闭包内启用另一个线程对 map 进行修改，在 Android 上，你还要考虑闭包内持有 ctx 导致的内存泄漏的问题）。

另一个角度是函数尽量无状态。不要引用超过函数生命周期的变量，这样会使逻辑清晰很多，知道输入就知道输出。

所以 stream api 还是香的。

线上事故吧？

+1，现在都是到 Safari 打开复制😹

@rosu “前段”更正：前端

1 楼和 3、4 产生了截然相反的回答😹。

首先一定要协商好，形成规范。另一个如果前段是 web，可能 null、“” 或 不传问题都不大。因为 js 是弱类型。

如果前段是 App，尽量就不要类型混用了。接口是 int 就不要返回字符串。因为你说了 0 和 null 意义不同，那假设这个接口开发之初就有此业务需求，意味着 App 只能用 String 或 object 来接了。

但是如果是接口后期升级，那还是协商前端升级版本做变更。

主页样式一直可以自己设置的，我的版本是在主页右上角三点菜单。可以去设置里看看

墨菲定律的意思该是：只要有可能失败，那就一定会失败，但是你无法知道什么时候会失败，这个失败发生在谁身上。

@lychs1998 感谢回复。看了您的代码，实现方式就是遍历取值建立映射。我们之前也考虑过这样实现。唯一担心的还是耗时问题。如果直接把 json 丢进去转，正如您上面说的，时间复杂度会是 O(m*n )。如果 json 数据比较多（列表信息之类），可能会有潜在的性能问题。（只是有这个感性担忧，没有量化）。

所以我们当时的做法是兼容接口，因为这样的接口是少数，所以采用手动解析的方式，只遍历和取值到业务需要的键值。

不过您的代码对我也有很大启发，非常感谢～

有一说一，如果真如楼主内容说的：key 和 value 都是字符串，那么问题不大。无非用 Map<String, String> 接然后遍历上报。

但是如果 value1 和 value2 里面是一个对象的话，那就比较蛋疼了；如果还要取对象里的值的话，那就更加蛋疼；如果 Android 这边用的是 Gson，那就非常蛋疼了。

之前遇到，同一个 key，返回不同类型的 value。分别是 String 和 Object。处理起来贼麻烦。

@frankmdong 是的，我也根据帖子里的评论用火绒保护了。疗效显著。

@killsting 一直是官方版，昨晚还自己检查更新并升级到了最新版。

不是吃内存吗？ 3600x 和 3600 差距不大，直接上 3700 吧。但是...还不如加满内存条来得实在。

只要 3x。可能是我们项目太小了（？）

最简单先看 3 动画是否开始。