天天用的东西坏了确实糟心。不过售后不是很好的品牌也只能这样了。修回来有新故障返修也是正常，他们售后不能真拿米和水试机吧。反正修三次没修好可以尽量咬定是同一问题要求换新。 退款好像得没有同型号才能退。

[awesome-selfhosted/awesome-selfhosted: A list of Free Software network services and web applications which can be hosted on your own servers]( https://github.com/awesome-selfhosted/awesome-selfhosted#pastebins)

随便挑，哈哈

我部署到国内虚拟主机，提交到 git 仓库后，用 action 构建静态站点并用 ftp 上传到虚拟主机上。

没太看懂 op 需求，我硬答一下🤣

软件或硬件: 自部署服务或 MCU 玩起来🤣

坑？只是设计的局限性吧，哪有什么十全十美的东西。后来者做得如果不如前辈，才能被前辈这样指点。感觉只是口嗨。

@TravisMtg 我猜测是 docker 自己或者他配的规则已经能把所有网卡的这个端口的流量转给容器内了，所以 100.64.70.88 能访问，不能访问是出在 100.96.113.29 -> 100.64.70.88 -x -> 10.112.91.240 这个不能的地方需要机子开转发。

加个电子狗功能？

似乎我在软路由上没遇到过你说的问题。

这个解决了什么？推流也得说说你的推点啊？

要不是有所谓了商补民，我看这事本质上是租带宽啊，为啥会有流量计费一说？

家宽跑 PCDN 是违法的，即使想搞流量计费不能说为了解决 PCDN 问题吧？

联动的话 MQTT + WS ，硬件 TCP ，小程序 WS 。
小程序、硬件、MQTT 都走公网。硬件主控用 ESP32 这种自带 WiFi 的就很合适。

前两年用 Miniblink ，很多特性不支持，如果不是为了兼容 win7 是真不想考虑。小是真的小，如果在意体积，做简单页面并且要兼容过时系统，是一个不错的选择。

因为 b 机子没开转发的话，就不能像路由一样在两个网口之间交换数据。

大概这样，不太专业，我最近也在折腾组网，我是这么理解的

我感觉复杂的项目或许用 Angular 比较合适。React 的方向感觉比较适合碎点的东西。
这俩框架各占一山头

数据库里存的精度就决定了 A 方案是切实可行的。

我一直用 A 方案，数据库精度是毫秒所以用 ISO8601 格式传精度也固定在毫秒。

这样前端显示也方便，不用转。后端在数据切片里取数据直接截断时间文本就能当索引用。

全部闭区间，以后不用想这次接口到底哪边开哪边闭，减少脑抽时刻。

我会从 Tauri 和 Electron 之间二选一。简单 UI 选 Tauri 减少应用体积，复杂 UI 选 Electron 避免花时间在跨 Webview 。