尝试使用外链图片本地化之类的插件预处理一下。
DIY 的图片数据是从附件表里拿的。但是外链图片不进附件表。

依稀记得 DIY 的里面应该没有嵌入点能用于插件开发，不靠本地化预处理解决的话可能得另外开发个插件什么的。

理解有一点偏误。不管是推模型还是拉模型，前提都是 Client 连到 Broker 建立长连接。

简单点来说：推模型是订阅 topic 之后，服务器主动在这个长连接里面给你推数据；而拉模型是相当于请求对应的 topic ，服务器再给你传过来。

换句话来说，对线上的 Broker ，不需要处理“怎么找到你的服务”或者“怎么连接到你的服务”这个问题，因为所有的操作都是建立在你和 Broker 的长连接的前提下。

你贴的这个聊天记录，讲的是在 NAT （ IP Masquerade ）网络环境下，怎么去保持这样的一个 TCP 连接的，对应的网络设备上会维护一个 NAT 表项，对于 UDP 和 TCP 会有不同的保活机制、超时时长。和应用层上的消息队列没啥太大关系。

@momocha 已经下载了，准备订阅。提个建议，是否可以有短时的订阅前的试用。例如可能 15 分钟？

大概率是根据 reference 来跳转到别的页面。比如搜索引擎进来的流量可以被他导到他的 apk 下载页面。
而网站管理者因为一般都是直接访问的，可能浑然不知。

建议查查服务器那边是不是有人进来动过了。

间接节省 IPV4 资源？
按照电信内的培训资料说的，云宽带目前业务上（暂时）不分配 IPV6 ，猫直接充当二层交换。

不知道局端会不会增加内网流量审计了。

支持一下，感觉不错；

《程序员重生之我是小学生》

国内标准的话，直接搜索：GB/Z 20177 一共有四部分。

https://www.lonmark.org/technology/lon-technology/standards/

不同国家的协议标准略有差别，注意区分。

适配工作量大。各个软件对于深色模式的行为各有区别。

不知道有没有用过 HMS ，或者 Yubikey 这类的产品。使用其做加密、签名验证之类的就需要你去用手触碰一下。
FaceID 需要双击电源键，也是一样的道理。确保不会被软件层面的劫持。

自从上次向日葵在我 MAC 上吃了 9G 的内存之后，就换到了 ToDesk 。

感觉描述有点问题。“主板之间的数据交互”和“客户端、服务端”，这两个描述是两个领域的概念。一个是底层的板级接口，另一个是操作系统上的概念。当然应该也有用纯硬件去实现服务端的，FPGA 这类。

个人拙见：直接写驻留后台的应用就行，都在安卓层面了，HTTP 接口、RPC 接口啥的都行。

从 Win 本转来，刚上手时觉得边缘略有锐利的，但很快适应。至于刘海，感知不强。

@mfmal 蹲一个故事

UGC 类得慎重啊。

打广告也不能这么打啊

大一可以先泛化得了解各类东西。但一定要学好专业基础课。有条件了可以深挖一个方向，了解原理。