-
Go语言不适合GUI开发，因其goroutine模型与GUI所需的单线程eventloop存在结构性冲突，导致UI卡顿；第三方库仅是补丁式方案，而Webview方案（如Wails、Tauri）才是当前可行路径。
-
根本原因是未调用Start()或Run()；路径问题（如Windows需cmd/c）、shell特性失效、输出处理方式错误（StdoutPipe需Start+goroutine+Wait）、超时需context手动Kill、交互式命令缺PTY支持。
-
sync.Cond必须与锁配合使用，传入锁的指针（如&sync.Mutex{}），Wait前需已持锁；条件检查必须用for循环，先修改状态再Signal/Broadcast，且变量读写须受同一锁保护。
-
不能直接用encoding/json解析二进制协议，因其非文本格式、无字段名和结构标识，json.Unmarshal会报invalidcharacter错误；须用binary.Read按字节偏移、大小端和固定宽度类型手动解析。
-
需确保解密输入长度为16字节整数倍，正确分离IV、去除PKCS#7填充，并用GCM等带认证模式替代CBC，同时校验解密后数据完整性。
-
告警抑制不生效的主因是标签不匹配，Alertmanager仅严格比对source_match与target_match的标签键值；需用真实告警JSON校验标签、将抑制依赖标签纳入group_by、用amtool离线测试，并注意抑制仅作用于新告警。
-
核心是“要不要”而非“能不能”：标准库encoding/json已足够健壮，自写反射序列化仅适用于需绕过标签规则、序列化私有字段、注入元信息或对接非标协议等特定场景。
-
Go不解决高并发，关键在于用goroutine和channel构建可控控制层；需防goroutine泛滥OOM、监控数量、限制资源池、用带缓冲chan+workerpool控流并优雅关闭。
-
必须区分/healthz和/readyz：/healthz仅检查进程存活（时钟、goroutine、HTTPaccept），/readyz同步验证依赖（DB、Redis等）；/readyz需≤3s响应、用atomic.Bool缓存探测结果、返回503而非500。
-
sql.DB本身就是连接池，无需第三方库；它自动复用、创建、回收连接，调用Query/Exec时借还连接而非新建；需正确配置SetMaxOpenConns、SetMaxIdleConns和SetConnMaxLifetime，并在首次查询前设置，且必须调用rows.Close()等归还连接。
-
合理设计指标类型与粒度，避免高基数标签和过度使用Histogram，预聚合数据以减少采集压力；复用*Vec指标并延迟初始化，缓存常用标签实例以降低开销；分环境控制暴露范围，动态启停采集器，调整scrape_interval；重用LabelPairs，限制活跃序列数，及时清理过期指标，减少GC压力。
-
Go模块缓存是Go工具链自动维护的本地目录，用于存储已下载模块以加速构建、避免重复下载并支持离线开发；默认路径为$HOME/go/pkg/mod（Linux/macOS）或%USERPROFILE%\go\pkg\mod（Windows），通过硬链接或复制复用缓存文件。
-
够用，但仅限学习和本地调试；真实项目中直接用map存用户会导致数据丢失、并发panic、无法查重分页，需第一版就考虑存储边界与并发安全。
-
答案是：空接口interface{}底层为eface（含_type和data），非空接口（如io.Reader）底层为iface（含tab指向itab和data）；二者结构不同，用途分明。
-
关键在于流式控制读写节奏：用bufio.Reader（64KB缓冲）封装文件、手动处理UTF-8BOM、设FieldsPerRecord=-1应对字段数不固定；读取用Read()循环逐行处理，禁用ReadAll()；写入用bufio.Writer（1MB缓冲）并每万行Flush()，禁用WriteAll()。
