结合上下文应该就是 API 的入口点。不同入口点对应不同 API，The endpoints indicate how you access the resource，经常是一个 URL 。

端点

转行为啥非要转计算机。感觉太可惜了。

gen8 为啥要退役呢

我猜是 Memory ballooning 的锅

准确说是 next 一次从 buffer 里取一条数据到 lastcols，至于你说的数据库和客户端的网络开销和交互取决于 buffer，是 driver 的事情，由 client 和 server 端配合来进行管理。
sql 的 next 定义参考 https://golang.org/src/database/sql/sql.go?s=77737:77764#L2732
对于 mysql 如 go-sql-driver 这个 driver 在 packets.go 里有 readRow 调用 readPacket 来管理 buffer.go 定义的 buffer 。
对应 mysql server 端的 https://dev.mysql.com/doc/internals/en/com-query-response.html
其他数据库 server 和 driver，也可以对应研究一下。

DHL 这种分布式 k-v 感觉只能类似于广播的形式传递信息，只是对消息进行端到端加密，然后两边约定一个 key 生成模式去轮询，不过 DHT 网络上广播消息进行传递估计效率感人。

可以但是没必要

@hakono 其实不必太拘泥于 git flow 的话，只要不同 feature 是基于同个 develop 或者 master 创建的，发版前只需合并需要的 feature 分支到一个新分支，然后做集成测试。最后 release 即可。在 git flow 里，单 develop 只是起了个汇总作用。

@hakono 但是理论上来说因为有多个 feature 和 develop 的存在，每个 feature 在合并到 release 之前都要测试和 develop 还有其他 feature 的兼容性，确实是需要先合并到当前 develop 分支的全部代码的
如果只基于当前 release 代码进行 feature 开发，不想合并其他 develop 代码，要不然考虑一下 hotfix ？

"如果有人没注意到这件事想发布 feture/image 到生产环境，把 feature/image 合并到了准 release 环境的分支上"
这是什么操作。不应该先到 develop 再从 develop 统一发版么。直接从 feature 到 release 真的大丈夫

我理解是由于成本和效率的考量，真正的完全去中心化没太有必要。只要把挂掉的概率降低到可容忍水平就行了。

这么看降低成本的话还能再撑撑。

被 ddos 了

2.4 没问题啊，穿透力强，稳定性好，对 iot 设备的兼容性好。

@FakeLeung 我用的骷髅峡谷完美黑苹果

NUC 他不香吗