2021年6月25日11点37分:
可以去研究flutter了，后端已完成，真是个旷日持久的战争啊。
2021年4月11日07点17分：
node与river的区别在于，node是跨越项目跨越客户需求的存在，是构成所有项目的基本单元
river是node的容器，river是项目与客户需求的具象化，具有高度的确定性
river就像是一块泥土，制造成不同项目，不同客户需求的形状，确定这形状无懈可击后，放入火炉烧硬
一千个客户需求有一千个不同的river
同时river也是数据流动框架意识的具象化，river与river总是会进行相互连接，从而表达出数据从哪里来与数据会到哪里去
反过来“数据从哪里来与数据会到哪里去”就是构成一个需要用数据流动框架实现的客户需求的最基本组成单元
从flutterUI客户端发来的开门或修改配置之类的事件绝对不能转化成event，而是该转化成类似mvc框架中model的对象的形式
于是这个“数据从哪里来与数据会到哪里去”的形式如下：
flutterUI.Door.Baits->Server.Door.entity->Server.OpenDoor.Modbus
2021年4月3日1点16分：
golang中只要是需要进行new与make才能使用的数据类型，在没有进行new与make之前都是连分配内存都没有进行过的
2021年2月27日21点16分：
今天达叔去世了
数据采集项目最开始的时候，我就遇到了最初也是最终的问题
那时一直很迷茫，因为在做程序的时候找不到某种类似目标的东西，这个目标不是项目完成的那一刻
而像是你在一个湖的中心划船，四周都是雾气，能见度低的吓人，别说岸边，就连稍微远一点的地方都看不到
有需要去实现的需求我只会各种查阅资料，一旦有能够实现效果的方式拿来就直接用，而不会去考虑任何诸如“是否简单”，“是否合理”，“是否耗费资源”，“使用方式是否正确”，“是否可以复用”这些问题。
更不会去考虑“会对之后程序的扩展性有何影响”
其实也不是不考虑这些，而是没有能力去兼顾这些
现在不一样了，拥有兼顾这些的能力，就像是迷雾中隐约可见的一座灯塔，虽然只是能依稀看的清远方的光亮，但已足够让我知道何去何从