@makelove 2 倍的 long, 16 字节, 打错了, mysql 用了 char32, 它应该是没提供原生的 uuid 支持

@makelove uuid 并不浪费内存, UUID 在很多数据库的实现中使用了 8 个字节, 也就是 2 倍 long 的长度, uuid 完全可以做到高效, 除非性能特别重要, 而且单个表数据极大, 否则选择 uuid 是一个很不错的选择, 性能是一个需要基准测试问题. 绝大部分系统的性能问题都不会因为你使用了 UUID 而导致. 反而我非常推荐使用 UUID 作为 id.

@erquiasz0825 因为按照分页查询时候, 数据会分散到不同的页, GUID 这种如果要作为主索引, 一定要支持自增, 否则插入 /查询都会有不小的性能损失. GUID 有自增的算法版本

非常麻烦, 我们的很多项目也是这个性质, 一个 core 分支, 每个人一个 dev 分支, 一个 main 分支(合并每个人的开发), X 个定制分支, 非常烦, 每次为 core 做 fix 或者 feat 都要重新 rebase, 然后重新测试. 一直没找到好办法. 但项目性质决定了, 赚的就是给客户定制软件的费用, 维护麻烦也是要做的.

@wdc63 没有这种数据结构, 不用找了

前后端不跨域的情况, 都直接使用相对地址发起 ajax 或追 fetch 请求就好了嘛

取决于你的前端是否和后端部在再同一个 IP 的同一个 Port 上.
也就是$protocal://host:port 这个部分只要前后端是一致的, 那么可以使用相对地址. 不过一些复杂的网站的 service 的 url 特别多, 肯定是需要写死在前端, 或追至少要写死一个 1 个获取其它地址的统一入口地址.
例如: Nginx 代理: 192.168.0.1:5001(API+vue public resources), 局域网直接使用局域网地址, 然后 Nginx 使用 https://host 访问, 所有 API 都是以相对地址请求: post: /api/app/token 这种, 没啥问题

@feller 一直使用 scp -r $dir $dist

用过 three.js, Unity3D 结论是效果都不够好. 需要优化的地方太多. 做的漂亮要看设计和美工. 做的顺滑就需要优化上下大力气. 我是没有耐心再搞这个玩意了.

去 github 上搜索, 基本上每个方向都有人做技能树. 但计算机领域实在有太多方向了, 人力有限, 也只能选择几个有限方向, 越是深入, 领域就越是细分. 但最基础也是最核心的, 就是 CS 考研需要考的哪几门.

@LeeReamond 我晚上回去打 log 看下各个地方的耗时, 我现在都没有跨网络, 本机测试延迟都是 1400ms, server, provider, render 都在本机.

2MB 的 base64 str(本来是 bytes, 但因为某些原因, 我需要将其编码为 base64), 然后还原到 bytes-> 然后转换为 numpy, 然后转换为 tensor, 然后使用 mayavi 显示(10W-20W 个 point cloud), 最终就是非常慢. 反序列化这一部分就已经需要秒级了. 最终完成一次窗口绘制, 时间就超过 5s 了. 主要还是二进制序列化太消耗时间了. 不做二进制序列化又太大, 一次网络传输 20MB, 大概需要 10s(香港到大陆). 我想想该怎么优化.

@LeeReamond 2MB 的 base65(本来是 bytes, 但因为某些原因, 我需要将其编码为 base64), 然后还原到 bytes-> 然后转换未 numpy, 然后转换未 tensor, 然后使用 mayavi 显示(10W-20W 个 point cloud), 最终就是非常慢. 反序列化这一部分就已经需要秒级了. 最终完成一次窗口绘制, 时间就超过 5s 了. 主要还是二进制序列化太消耗时间了. 不做二进制序列化又太大, 一次网络纯属 20MB, 都需要 10s(香港到大陆). 我想想该怎么优化.

@LeeReamond 没找到好的办法, 只能使用多进程, 然后使用 Queue 做数据通讯, 但真的很慢很慢. 你用过 mayavi 库吗? 是否有性能优化建议, 这个库启动非常耗时, 每次至少需要 3-10s, 每次同步的数据数据比较大 1-10MB, 然后还需要从 str->bytes->目标数据结构, 最终体验非常差.

另外, 对外在能考虑到的情况是不会抛出系统级别的异常的. 如果事前没有考虑到, 那么就让他直接奔溃. 由宿主层去考虑要怎么执行下一步操作.

主要要看你处于什么层次, 你做的这个层的消费者是谁, 如果你作为一个底层库, 要看错误是谁导致的, 如果是用户入参有问题, 我们就是抛出异常, 如果是内部的不受控的上下文依赖导致的问题, 也是直接抛给调用者, 如果是内部业务逻辑错误, 也直接抛给调用者. 如果是外部调用者(普通用户或第三方 API 调用者),那么就需要在外层统一处理一下. 主要是大部分错误就没法处理. 直接返回给调用者. 主要是看是逻辑错误还是其它. 说白了, 异常是一种偷懒的流程控制手段, 看你怎么用.

IoT 设备的核心问题是很多厂家生产的硬件设备的协议是不开放给第三方的. 而且很多协议是私有定制化的, 就这一步, 就搞死了大部分用户. 各家都都指望靠这个 2 头收钱(硬件生态生产商加入需要收钱, 开发者接入需要收钱). 这些都是利益. 如果将接口都开放, 就没有生态一说, 产家就变成买设备的. 而平台就没啥用了!

@bbsabc2 你们是学校, 不是培训机构. 如果这么急功近利, 最好不要从事这样行业. 好好学数据结构, 算法, 操作系统, 计算机网络, 软件工程等核心基础课程才是正道. 如果那么基于发财, 不如去炒虚拟货币.

@mmddisa 没什么问题, 一切正常使用, 把你的 DNS 配置贴出来
@codefever 不解决问题, 就不要发废话