cnuser002

楼主的担忧我能理解。比如一个发送端，一个接收端。

我当然希望每次接收端收到，都是一个完整的消息，不就能直接处理了么？

但如果这个消息，真的很大呢？ 或许他一次发送不完，那我收到的就不全。我要等，这可就麻烦了呀。同样的，下一次把之前的尾巴，跟下个报文的头給一起发送了，我还得拆，更麻烦了。

嗯。Tcp 它就有这种操作，这不是它的问题，而是它的设计，就是基于 Stream ，像流水一样一直给你灌数据。 底层打散但是保证消息还是前后有序进来的。对于这种流，需要按流的处理方法，收取后进入缓冲区，然后在缓冲区里，根据协议里面的约定，比如固定包头，特殊符号来解析出内容。

而这个就是 HTTP 干的事情。 所以你的需求，用 HTTP 就可以实现。你可以认为 HTTP 接口每次拿到的，就是完整的数据。

WebSocket 也可以。

对我来说，首先是 NAS 的本身涵义，网络附属存储。

家里最初只有一台主力电脑，游戏，照片，电影等数据都在这里。这时对网络存储，没有需求。

但是渐渐的，家人们随身的手机，床头的平板，客厅的电视。这些设备，他们的存储容量偏低，自身的数据比如照片等等，需要经常导出；另一方面，类似看电影电视剧，又需要从外部拉取文件。

这个时候还靠那台已经不怎么开的主力电脑，干这个事情就不太合适了。

需要专门有个网络存储，供局域网里的设备共用。
我也试过一些方法，比如说，在家庭 Wifi 下挂载一个移动硬盘。权宜之计，能用，但可以更好。
所以当有了折腾的余裕后，就买了硬盘盒，加上小主机，自己 diy 了一个 NAS 。
实现了本地网盘啊，本地媒体库啊，电影分享，照片备份等等功能。

拥有了 NAS 后，从另一个角度，就等于有一台家庭服务器。那自然可以整点服务器的东西玩玩。挂一些服务，搞一点应用，这时 NAS 就是个容器。

我所知道的响应式设计，是一种布局思路，用这个思路，对不同宽度的屏幕，都能给出一个相对合理的排版。

这里的不同宽度，不仅仅是 PC ，也有 Ipad ，折叠屏，甚至手机横过来。

这个思路的要点，是优先考虑屏幕窄的情况，满足最窄屏幕的布局后，对于更宽的屏幕，可以扩大间距，拉伸组件，增加分栏，总之把它填满。

这里面竖屏手机是最窄的，所以响应式设计，也以“移动端优先”。

这跟业务上 PC 端摆烂，专注 APP 那种“移动端优先”，不是一个意思。

但实际效果，普遍没有想象中的好。首先因为手机的屏幕，相对于 PC ，实在是太窄了。手机 APP 很多是用层级菜单，底部导航栏等适配手机的组件，这些东西放到平板那个宽度，就不好沿用了，想好看的话，还是得重新设计布局。

其次，响应式设计，你得用它的栅格系统，这样的话，你的组件的宽度，组件大小，都是被限制的，不容易跟设计稿对齐。

所以我看现在像 douyin 这种愿意做 web 端的，也都是分两块。移动端弄个 m.域名，直接给你干到 app 下载页，web 端重新设计，从平板的宽度开始，向上用响应式。

Python 本身就是强类型语言，只是它提供许多默认的转换，让你可以直接转数据类型。这点写脚本很方便，不然 JS 也不会有那么多 [魔法]

现在 Python 也有代码类型标注，写的时候带上这种也是可以的。

第一个问题:

现场设备是 A ， 物联网平台是 B ， 手机应用是 C

A 要主动把数据，按 B 定好的格式，传给 B 。 然后 C 按 B 定好的接口，从 B 查数据。

C 要控制 A ，就按 B 定好的接口，給 B 发命令，B 收到命令后，转发給 A 。A 收到后执行。

B 对 C 开放的是 HTTP 接口，或者 Websocket 接口，不涉及到 Native ，所以 C 该怎么开发怎么开发。

Flutter 还行，RN 略有过时，写过 React 可以路径依赖，没写过推荐 Flutter 。



第二个问题

A 跟 B 怎么连，两种情况，

如果 A 本身是一个能主动往外推数据的设备，那么它默认有一个对应的 A*平台的格式，你可以自己搞个 B ，兼容 A*的格式，然后修改设备的发送地址。或者你就用 A*的平台，自己写个中间件去拿。

如果 A 本身不是所谓的物联网设备，那么它一般不会是一个能主动往外推数据的设备，需要放一个网关 D, 转成能往外推数据的设备，D 一般有个对接的平台 D*，你可以用它的平台，也可以兼容 D*的格式，弄个自己的。

像阿里，aws 那种，希望你是一个设备生产商，让你的设备，直接接入它们平台，让它们来代管。对你来说，中间的数据存储，流转，就不用你自己操心了。

说说我的体会，
1. 写刷法题，完成小作业，这种场景 C++和 Java ，没有太多区别。
2. 有 IDE 的加持下，用 C++写 windows 桌面程序，和用 Java 写 Android 移动端程序，体验也差不多。同样的模式，都是在预设的框架里按套路写。
3. C++写网络编程，就比较麻烦了，Java 写则很简单，或者说，不简单的地方，已经有高手为你写好了。
4. C++写完了并不算完。头文件管理，交叉编译，调试等等都费劲。尤其一个叫 cmake 的东西，当年把我狠狠干住了，发现没有 Visual Studio ，咋干啥都不顺。Java 这块就轻松多了。

后面用 JS ，Python ，又体会到一种语言在“领域内的垄断”。 比如 JS 在前端，Python 在科研，JAVA 在网络，那 C++呢，则在所谓的高性能领域，什么游戏引擎，网游服务器，音视频处理，高性能硬件开发等等，这个领域本来就费脑子，开发效率天然就低。

我想到上学时候的一个梗：
什么时候可以抄作业?

1. 遇到你会的题目，可以抄作业，节省时间
2. 遇到你不会的题目，可以抄作业，学习思路。

所以遇到会与不会的，都可以抄。

但抄作业不是目的，掌握知识，应试技巧，锻炼题感，拿到高分，这才是目的。

而如果只应付每天的检查，盲目的抄写，几个章节后你很可能就不知道你在抄什么了。

文章反映的也是类似的问题。


我们现在用 AI 编程风生水起，有一个前提被有意无意的忽略了，就是大家多多少少在没有 AI 的时候，学习过编程，有些底子，你去抄 AI 的东西，有底。

倘若过于依赖 AI ，就好像只抄答案不看过程，那久而久之，也就看不懂过程了。不就文盲了么。

@Curtion 有些做硬件的厂商，它想上云会用类似阿里这一套，终端适配阿里，然后不用自己云平台后端，按他給的范式走配一配就行了。

多少有点先入为主的感觉，我是从启蒙阶段用的 vs ，
后来用过 idea 一段时间，那会也感觉 idea 是什么垃圾 啊，用不习惯。到最后也没把这玩意弄趁手。

但是 vscode 就很舒服，回头感觉 vscode 还是更接近 idea 一些的。就是 idea 也是有亮点的，当时感觉不出来。

vs 到底吊在哪，我觉得作为 Windows 端开发软件，它的大而全。比如开发 c++，除了写代码外，编译链接那坨头疼的东西它給你代管了。调试什么的他也做得