能简单说一下原因吗？
在服务的最底层，肯定是基于领域来开发的，但聚合这件事本身逃不掉，要么在后端做，要么在前端做，所有这里仅讨论放到哪里做合理。

>> 小插曲：顺便写到这里想到一个问题，大家对前后端的理解，会不会不一致？比如 H5 端、App 端肯定算前端，那么 node 端呢？我理解严格来说 node 端是不严谨的说法，但为了交流方便这里借用一下这个概念。或者严谨一点，如果用一个 nodejs （获取其它技术） 把业务接口进行了聚合，那么这个 nodejs 算前端还是后端？（我后面的描述把这一部分仍算作后端，如果大家定义不一致可以探讨）

继续探讨放哪里合理的事，我个人认为放到后端因为：
1. Android 、iOS 绝大多数情况下，只需要做一次聚合逻辑
2. API 形式的对接，更容易做测试。（不是说不能做，但更容易，可以探讨，我也没有在查到太多在 App 内做“单元”测试的成功案例，注意这里“单元”打了引号，因为严格来说，直接测 API 不属于单元测试范畴）
3. 调整业务逻辑不需要用户升级（仅限 APP ）
4. 日志更容易获取，方便解决问题。（同样是相对来说，我了解 App 有各种日志上传的方案，但这个因为比较敏感，网上资料不多）

另 @ChanKc @ppphp 提供的 graphql，之前了解不多，需要去细看一下，感谢

经常打的字会变成 VIP 专用字

国产电视集成乐播投屏方案，airplay 已经很成熟了，经常用 macos 投屏开会，除了现在乐播强制加了广告

@wunonglin
1.是否你的每个 for 在不同的 go 程，打印出来看看
2. 加延迟，晚点发

1. 看一下你给的链接里的 demo，https://github.com/labstack/echox/blob/master/cookbook/websocket/gorilla/server.go 。Subscribe 里 readLoop 不应该新开 go 程，直接卡在这里，直到 ws 断开。因为 Subscribe 是 HTTP Server 调的，你返回了，它就会认为这个连接已经结束了，虽然不一定会马上关(keep-alive)，但必要的时候会断开。

2. 作为一个 HTTP Server，Subscribe 应该是在不同的 go 程里被调用的，不然就就成了单协程了，你可以打印出来试一下

借地方顺便问一下，Clion 你们怎么搞定环境变量的问题？
比如我的 cmake 会根据环境变量，加载不同目录的不同代码，这些代码实现了相同的接口，比如驱动的封装。
碰到这样的代码，我的 Clion 好像什么提示都给不出来

为何楼上各位都不考虑前后端分离呢？这样后端要做的，与 C 的交互，不就仅仅保留了一些简单的数据或者说设备状态。比如用 RPC 来查询主工作进程。

至于一个静态的 HTTP Sever 部分，那个简单的开源版本，几本可以直接用了。

看起来关键分歧在如何理解“配置了节点 机器 b 的信息”，如果这里指的是 jenkins 的 slave 节点，那么在 B 上运行 1 和 2.
但后面提到只是在 B 上运行，那边 B 就仅仅是部署机，1 和 2 在 A 上运行。
所有关键是，“配置了节点 机器 b 的信息”具体指什么

“听说”一词，说明在技术选择和方案设计上，你是被动的。为什么不是我们做了 xxx 分析以后认为应该改到 websocket ？

@dangyuluo 其实不要以为这里把顺序调整对了就好了，你会发现后面还有别的顺序问题。只有 group 最可靠

target_link_libraries(main
-Wl,--start-group
c++
c++abi
m
c
gcc_s
-Wl,--end-group
)

好用的定义是什么？

@47042 思路类似，原厂是怎么防止你刷 Recovery 的，你就怎么防止别人刷。不过你可能需要 fastboot 或者更底层 boot 的源码，这可能有点困难。

自己编个 Recovery，验证自己的签名。原厂的 Recovery 就是这么玩的，只不过你没有它签名的私钥而已。

第一感觉这个方案很奇怪，关注一下听听大家的说法

这道题，感觉怪怪的。开 3 个线程，然后居然没有一点并行的需求