-
Go高并发I/O核心是goroutine+net.Listener组合：Accept后立即gohandleConn，需设读写超时、用sync.Pool复用bufio、禁用syscall事件循环。
-
设计RPC接口时方法需大写、接收者为指针，参数返回值用结构体；2.优先选用Protobuf+gRPC或JSON-RPC替代默认Gob以提升跨语言兼容性；3.客户端应管理连接生命周期并处理超时与错误；4.服务端需校验参数，分离业务逻辑便于测试；5.添加日志、监控和健康检查提升可观测性。
-
Go使用Protobuf需先安装protoc编译器和protoc-gen-go插件，再编写.proto文件定义结构，如Person消息；通过protoc生成Go代码后，用proto.Marshal和proto.Unmarshal实现高效序列化与反序列化。
-
Go标准库支持HTTP压缩与解压，客户端需手动压缩请求体并设置Content-Encoding:gzip，服务端需解析该头并用gzip.NewReader解压；响应方面，客户端默认自动解压gzip，服务端则需根据Accept-Encoding手动压缩并写入Content-Encoding头，通过中间件可实现请求解压与响应压缩。
-
Go1.21+编译WASM仅支持GOOS=jsGOARCH=wasm，需配合syscall/js和官方go.js胶水脚本运行于浏览器，不支持WASI或独立wasm引擎。
-
直接用http.FileServer默认不缓存、不压缩、不fallback、路径校验松散，易致404或性能低下；核心问题在于其隐式路径假设（如不自动补/、不查index.html）、相对路径风险、缺失Cache-Control与gzip、未防护目录遍历，且无SPAfallback机制。
-
直接使用gonum.org/v1/gonum/mat无需封装，但必须严格遵循行优先内存布局、显式指定接收者进行矩阵运算、正确处理NaN/Inf及维度对齐，否则必panic或结果错误。
-
channel不适合做HTTP负载均衡器，因其缺乏连接复用、超时控制、健康检查等核心能力；强行使用会导致contextdeadlineexceeded或connectionrefused，且无法按后端差异配置重试、TLS、Header等行为，也无自动剔除故障节点机制。
-
答案是使用Golang标准库实现一个简洁的CLI记账工具，通过Record结构体存储账目，JSON文件持久化数据，flag解析命令行参数，支持添加、列出、统计功能，程序启动时加载ledger.json，退出时保存，用os.Args判断子命令，add命令添加带ID和时间的记录，list显示所有条目，balance计算收入与支出差额，核心逻辑清晰可扩展。
-
Go中unix.Sendmsg传文件描述符失败的根本原因是SOCK_CLOEXEC标志导致fd被内核自动关闭，需手动创建socket并清除该标志，发送时正确设置SCM_RIGHTScmsg，接收后立即dup并转为*os.File。
-
os.WriteFile并发调用会覆盖数据，因不支持追加且非并发安全；正确做法是加锁、通道+单goroutine写或临时文件+rename原子替换。
-
Dubbo-go启动后注册不到Nacos主因是协议不匹配：JavaDubbo默认用dubbo协议，而dubbo-go0.9+默认用tri协议，需显式配置protocol:dubbo或升级至v1.5.x兼容版本。
-
binary.Read失败主因是未分包直接读net.Conn；TCP无边界，须先读协议头长度字段并校验范围，再io.ReadFull读完整包；禁用unsafe强转，应手动解析或binary.Read；长度字段自身字节序亦需与协议一致。
-
Go默认静态链接，生成单一可执行文件；自1.5起支持通过-buildmode=shared和-linkshared启用动态链接，可显著减小主二进制体积，但需配套共享库，总磁盘占用未必降低。Go默认静态链接，生成单一可执行文件；自1.5起支持通过`-buildmode=shared`和`-linkshared`启用动态链接，可显著减小主二进制体积，但需配套共享库，总磁盘占用未必降低。Go的链接模型与其他主流语言（如C/C++）
-
不能直接用map做多引擎缓存统一接口，因其内存独占、无生命周期管理、不支持序列化/持久化，且无法对接Redis、Badger等外部引擎；核心矛盾是各后端读写语义不一致，强行抽象易致类型断言或panic。
