-
Go依赖分析需结合golist-mall、gomodgraph和golist-f'{{.Deps}}'：前者查最终模块快照，后者定位路径与包级依赖，注意间接依赖、版本冲突及裁剪机制影响。
-
命令模式通过接口解耦发送者与接收者，将操作封装为对象，便于实现队列、撤销等功能。定义Command接口及Execute方法，具体命令如TurnOnCommand实现该接口，操作设备。使用CommandQueue存储命令切片，提供AddCommand和ExecuteAll方法依次执行。示例中电灯开启关闭命令入队后统一执行，输出三行状态。可扩展异步执行，如ExecuteAsync用goroutine运行，注意命令对象应轻量，避免过多状态，提升复用性。
-
errgroup.WithContext是并发错误处理的起点，需传入带cancel的context并在子任务中显式检查ctx.Err()，否则无法及时中断；Wait仅返回首个非nil错误，不汇总全部错误。
-
gRPC客户端调用超时必须通过context.WithTimeout显式传入每次调用，grpc.Dial的timeout参数仅作用于连接建立阶段；服务端需检查ctx.Err()及时退出；流式RPC需对整个生命周期统一使用同一ctx。
-
最直接方式是用sort.Slice配合优先级映射map[string]int实现自定义排序，避免字符串字典序错误；推荐结构体用int型Priority字段配合常量，输入时校验转换，输出时查表转回字符串，兼顾安全、性能与可维护性。
-
Example函数必须以大写Example开头、无参数无返回值，定义在同包的_test.go文件中，末尾用顶格//Output:断言fmt.Println输出，且需显式初始化依赖。
-
为什么net.Buffers比反复调用conn.Write()更快因为系统调用开销被摊薄了，而且内核能对连续的缓冲区做一次合并拷贝。每次conn.Write()都触发一次syscall（比如writev或send），而net.Buffers底层直接构造iovec数组，让一次writev处理多个内存段——这在发送HTTP响应头+正文、拼接TLS记录、批量推送日志时特别明显。但注意：它不是万能加速器。如果每个buffer都很小（比如平均<32B），反而可能因
-
通过gotest与benchstat可量化对比Go函数性能差异，需编写Benchmark函数、运行测试并分析ns/op与delta指标。
-
Go贪心算法成败关键在排序依据选择与贪心边界控制：区间不重叠须按end升序，教室调度需配合最小堆，哈夫曼编码依赖堆动态取top2，硬币找零仅对特定币制有效；贪心不回溯，遇非规范币制或复杂覆盖问题需切DP。
-
pkg-config找不到系统库：cgo编译直接报错Go的cgo依赖pkg-config自动发现C库的头文件路径和链接参数，但默认不继承shell的PKG_CONFIG_PATH，导致#include这类引用直接失败，错误里常带cannotfind-lssl或fatalerror:openssl/ssl.h:Nosuchfileordirectory。根本原因不是没装OpenSSL，而是Go构建时压根没调用或没配对pkg-config。解决
-
counter++在多goroutine下必然不可靠，因其被拆为读取→加1→写回三步，中间可被抢占导致覆盖；必须用atomic.AddInt64等原子操作，且需满足类型、对齐、初始化三前提。
-
replace语句必须严格匹配模块路径且右侧为绝对路径，否则gobuild会静默使用远端版本；需同步更新go.sum、清理缓存、验证路径，并避免提交到主分支。
-
Go中管道输入本质是读os.Stdin，无需预检是否为管道，应直接用bufio.Scanner或io.ReadAll流式读取，并显式检查scanner.Err()；多源输入时按“先试读、EOF则fallback参数”策略处理。
-
Worker池优于直接gof()：能复用协程、控并发、减内存与调度压力；需用sync.WaitGroup+context.Context确保正确退出，channel宜设无缓冲或小缓冲。
-
new返回*T类型的零值指针，仅分配并清零内存，不初始化逻辑或创建可直接使用的slice/map/channel；make才用于构造可立即使用的引用类型。
