用 json.Number ，尤其是会遇到大整数的场景

用 float64 的坑是遇到大整数，即使整数在 int64 范围内也会有精度损失问题
用 interface{} 也有问题，默认数字类型就会 decode 成 float64 ，除非 decoder 上用.UseNumber() 强制解析到 json.Number 类型

i3

按行读取试试

SCAN | while read k; do DEL $k; done

支持
开得爽最重要

家用？别想了，不可兼得


我是拆成 A35 + 530 了

win 安装
linux 安装
黑苹果安装
linux live
dos 系统，偶尔刷机
exfat 跨系统交换文件，网卡没驱动时救救急

没剩几个了吧？

@fastcache 维修更换主板后问题解决了。

java 增加日志记录订单对应的 ws 消息是否发送成功

小程序不在前台 5s 后会断开 ws ，不知道扫码唤起摄像头过程会不会出现这种情况

小程序再加个 http api 轮询机制，主动查看设备是否已成功打开，不要只依赖 ws 消息

因为这个协议就这么设计的啊，只有 tcp 和 udp

自己做的安卓短信转发 app ，用了 6 、7 年
存在几个问题：
低端机电池鼓包换过好几次电池，也干废过好几个手机，屏幕被撑裂
充电管理做的好的中高端手机不会鼓包
定时充电插座也没啥用，鼓快鼓慢的差别
app 保活难度在增加，有些品牌手机加白名单都没用，运行几天 app 被杀偶尔发生
wifi 偶尔会出问题，有些机器长时间开机 wifi 硬件会挂需要重启手机

反正偶尔需要人工处理一下，想长期无人值守运行，那安卓这个方案不够稳定。

8g 的 m1 air 用了 2 年多。适合移动办公改改紧急 bug 。项目大或者多开几个体验就差了


所以这么点内存当日常开发用还是算了吧

这个，服务器上用，不停机能更换 m2 的盘？

@aayyooh2 那就故障报修，让师傅现场改好桥接

打运营商电话，要求光猫改桥接模式，然后你自己路由器连光猫，再设置拨号

我也入了一块，顺便入了一块 2 块钱的 usb 声卡板子，打算有空了做成 voip 设备接入 freeswitch

@gitxuzan “这套架构搭建复杂吗，有成熟的具体方案吗？还有个疑问，你这一条 ws 是共用客户端和业务端共用？”

我们 2017 年就开始用这套方案了。

业务端不使用 ws ，业务端使用 http/grpc 和 [消息服务] 通信。 这样我们开发人员就不需要写 ws 相关的逻辑，当成 web 服务的逻辑来写。也和业务端语言无关了。

@lesismal 嗯，当时出发点就是堆机器，所以用了当时最可靠的 github.com/gorilla/websocket （ 2017 年）

golang 各种解决单机 ws 能力的方案还是最近几年的事情。

我感觉 websocket 的痛点是 1 支持大量连接 2.和业务解耦

我们公司是做了一套 ws 的基础服务
分成 2 部分
[接入] 部分，做成分布式可水平任意数量扩展，部署在各种廉价云机器上。
[消息服务] 部分，一般部署在业务所在集群，和每个 [接入] 器之间建立（一条） ws 进行数据通信，维护所有客户端信息。

业务端使用 http/grpc 和 [消息服务] 进行收发消息。
这样业务根本不需要关心 ws 处理，只要做消息回调和消息发送的处理。


接入：客户端先 http 请求一个连接 token ，此时会告诉客户端连接 token ，以及连到哪个 [接入] 点
发送消息：业务端---http/grpc--> [消息服务] ---ws---> [接入器] ----ws----> 客户端
接收消息：客户端----ws----> [接入器] -----ws-----> [消息服务] ----http/grpc---> 业务端


[接入] 和 [消息服务] 之间只使用一条 ws 连接交换消息，这样传输链路上的各种网关就不需要维护大量 ws 连接了。