应通过接口定义算法契约、避免暴露结构体，采用无状态函数设计、分层错误处理及边界测试。即用 graph.interface 等轻量接口替代具体结构体；算法接收预分配状态而非自行创建；区分 erremptygraph 等业务错误与系统 panic；重点测试 nil 输入、异常图结构与资源限制场景。
用接口定义算法契约，而不是直接暴露结构体
图算法模块一旦写死结构体字段或依赖具体实现，就很难被其他项目复用。goraph 的 Graph 类型本身是导出的，但你不该让自定义算法直接操作它的内部切片或 map 字段——这会把调用方和内部表示耦合死。
正确做法是只依赖接口。比如遍历类算法应只接受 graph.Graph（它实现了 graph.Interface），而这个 interface 只暴露 Nodes()、Neighbors(node)、HasEdge(u, v) 等有限方法。这样即使将来 Graph 底层从邻接表换成 CSR 格式，你的算法也不用改。
- 避免在算法函数签名里写
*graph.AdjacencyList或map[Node][]Node - 所有输入参数优先用
graph.Interface或你自己定义的轻量接口（如Reader、WeightedGraph） - 如果算法需要边权重，不要硬编码 float64 字段，而是定义
EdgeWeighter接口：Weight(u, v Node) (float64, bool)
把状态管理交给调用方，别在算法里 new struct
很多新手会在自定义算法里写 func NewPageRank(graph *Graph) *PageRank，然后把图、迭代次数、收敛阈值全塞进结构体。这看似封装，实则制造了隐藏状态和内存泄漏风险——调用方无法控制生命周期，也无法复用同一实例跑多次不同参数。
更可控的方式是把算法写成纯函数或无状态方法，把中间状态（如 score map、visited set）作为参数传入或由调用方显式管理：
- 提供
Run(graph graph.Interface, opts PageRankOptions) (map[Node]float64, error)，不返回结构体 - 若需多次调用（如增量更新），才提供可复用的结构体，但必须带
Reset()方法，并明确文档说明“非并发安全” - 避免在算法内部做
make(map[Node]float64, graph.NodeCount())—— 改为接收预分配的score map[Node]float64参数，方便 caller 复用内存
错误处理要分层，别把 panic 当流程控制
图算法常遇到的错误类型差异很大：输入图为空是用户误用，应该返回 ErrEmptyGraph；迭代不收敛是数值问题，应返回 ErrNotConverged；而内存分配失败（如 make 失败）属于底层系统错误，该让 panic 向上传播。
封装时必须区分这三类，否则上层无法做有意义的重试或降级：
- 定义明确的错误变量：
var ErrEmptyGraph = errors.New("graph has no nodes")，而不是笼统的fmt.Errorf("invalid input") - 对可预期的业务错误（如负权重环、无路径），用自定义错误类型实现
Is方法，方便调用方判断：errors.Is(err, graph.ErrNegativeCycle) - 绝不在算法内部
log.Fatal或os.Exit—— 这会让模块无法嵌入 CLI 工具或 Web 服务
测试边界比测通路更重要
一个封装良好的图算法模块，其测试重点不是“能算出正确结果”，而是“在各种烂输入下不崩、不静默失败、错误信息可定位”。goraph 原生测试集中在正常 case，但你自己的模块得补上这些：
- 传 nil
graph.Interface，看是否 panic 或返回清晰错误 - 构造含自环、重边、孤立点的图，验证算法是否跳过或报错
- 用
io.LimitReader模拟超大图，测试内存增长是否线性、是否提前 abort - 对浮点类算法（如 PageRank、Betweenness），用
cmp.Equal(got, want, cmp.Comparer(floatEqual))替代==
真正难的不是写出第一个能跑的版本，而是让模块在别人删掉几行初始化代码、换一种图构建方式、传入带 NaN 权重的边时，依然给出可理解的反馈——而不是崩溃、死循环，或者返回全零结果还声称 success。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
