-
Go中值类型与指针类型在编译期即为不同类型，运行时各自携带独立类型信息，行为差异源于类型本身、方法集规则及反射访问路径，而非隐式转换。
-
Go服务中暴露Prometheus指标需要引入promhttpHandler不手动实现/metrics端点，而是直接复用官方promhttp.Handler()——它自动聚合所有已注册的prometheus.Collector（如Gauge、Counter等），并按文本格式输出。自行拼接字符串或JSON会导致格式不兼容，PrometheusServer拉取失败。常见错误是只调用prometheus.MustRegister()却没挂载HTTPhandler，结果请求/metrics返回404；或者用
-
Golang的反射机制存在五个主要限制：首先，反射无法修改不可导出字段，如小写字母开头的结构体字段，调用Set()会引发panic；其次，反射性能较低，动态解析类型信息比编译期确定类型操作更慢，影响高频调用场景；第三，反射代码可读性和维护成本高，逻辑复杂易出错，调试困难；第四，反射导致类型安全缺失，错误只能在运行时发现，如访问不存在字段或调用不匹配方法；第五，建议尽量避免使用反射，必须用时应封装成通用函数、集中管理并添加清晰注释。理解这些限制有助于合理使用反射，保障程序稳定性与性能。
-
超时错误本质是context.DeadlineExceeded，须用errors.Is(err,context.DeadlineExceeded)判断；HTTP客户端需分层设Timeout、DialContext和ResponseHeaderTimeout；禁用time.AfterFunc替代上下文超时，数据库操作必须用Context方法。
-
Go的GC不会因指针存在而漏掉对象，判断依据是对象是否从根可达；不可达对象即使被非nil指针变量持有也会被回收，常见泄漏源于指针意外延长对象生命周期。
-
不能。FieldByIndex仅支持单层struct字段访问，不递归解析嵌套；对嵌套指针或interface{}需手动解引用并逐层校验类型，否则易panic。
-
推荐json.NewDecoder而非json.Unmarshal，因其流式解析不缓存全文、内存友好，且报错含具体行号便于调试；json.Unmarshal需全量加载字节切片，大文件易致内存暴涨且仅报偏移量。
-
答案：Go语言中可通过同一包测试文件直接调用私有函数，或提供测试专用导出函数来实现单元测试，优先推荐同包测试和显式测试接口，保持代码清晰可维护。
-
Go标准库encoding/csv默认支持RFC4180，能正确解析带双引号、换行及转义双引号的字段；读取需确保引号成对闭合，写入会自动加引号和转义；BOM与编码需手动处理，大文件应避免ReadAll()以防OOM。
-
答案是利用Goroutine和Channel实现并发爬虫。通过为每个URL创建Goroutine执行fetch函数，并使用Channel传递结果，实现高效并发抓取，提升爬虫性能。
-
会崩溃，且GC时必现；因reflect.SliceHeader无指针跟踪能力，手动修改Data会导致悬垂指针、内存破坏或panic。
-
在Go中，不能直接对类型断言结果（如any.(bytes.Buffer)）调用方法或取地址；需通过带短变量声明的typeswitch获取具名、具类型的变量，再安全使用。
-
测试文件操作不能直接写磁盘，因真实I/O拖慢测试、污染环境、不可靠且跨平台行为不一致；应使用afero抽象文件系统，测试用MemMapFs，生产用OsFs，并统一用filepath.Join处理路径。
-
因为if判断非原子，多goroutine可能同时通过导致重复初始化；即使加锁也易出错且性能差；sync.Once通过原子操作保障仅执行一次，更安全高效。
-
用net/http暴露指标端点需注册/metrics路径到默认或独立ServeMux，避免handler内耗时操作；优先读/proc/self/status获取RSS、结合/proc/self/stat计算CPU使用率；使用prometheus/client_golang时全局单次注册，动态场景用私有Registry。
