不能用crypto/md5或crypto/sha1做密码哈希或签名，因其存在实际可利用的碰撞漏洞，md5仅16字节、sha-1已被shattered.io等工具实证破解，仅限兼容旧固件校验等非安全场景；应优先选用sha256.new()，金融级场景可选sha512.new()。
grep -r 能发现哪些硬编码弱算法
直接在项目里跑 grep -r "md5\|sha1\|des\|ecb" ./，能快速揪出明显违规点。但注意：这只能捕获字面量，比如 md5.New() 或字符串里写死的 "AES-128-ECB"；它抓不到运行时拼接的算法名，也漏掉用别名导入的包（比如 import crypto "crypto/md5"）。更关键的是，sha1 和 md5 在签名场景中可能合法（如某些旧协议兼容），不能见名就删，得结合上下文判断是否用于密码存储或完整性校验。
go list -f '{{.Deps}}' 识别间接依赖的 crypto 包
有些模块自己没写加密逻辑，但依赖了用 crypto/des 或 crypto/rc4 的第三方库。执行 go list -f '{{.Deps}}' ./... | grep -E "(des|rc4|sha1)" 可列出所有引入这些包的模块路径。重点检查 vendor/ 下的库和 go.sum 中的哈希——如果某个库的 checksum 对应旧版本（比如 v1.2.0），而新版本已移除 DES，那升级就能解决。别只看主模块，github.com/some/lib 里藏一个 des.NewCipher 调用，整条链就算违规。
AST 扫描比正则更准，但要避开 false positive
用 gogrep 或自写 AST 分析器，能精准匹配函数调用节点，比如找所有 aes.NewCipher 的调用，并提取参数长度。但容易误报：比如 key := make([]byte, 32) 是安全的，而 key := []byte("123") 才是问题。建议加一层过滤条件——只报 len(key) 或 <code>len(key) == 16 && mode == "ECB" 的组合。另外，cipher.NewCBCEncrypter 本身不违规，但若其 IV 来自固定字节数组（如 []byte{0,0,0,...}），就得连同上下文一起标为高风险，不能只看函数名。
为什么 crypto/rand 用错也算违规
很多团队以为用了 crypto/rand 就安全，结果写成 rand.Read(buf) 忘记检查 error，或者用 math/rand 生成 IV——后者输出可预测，等同于裸奔。检测时要扫 math/rand 的 import 和所有 .Read() 调用，再交叉验证返回值是否被忽略。真正的红线不是“用了什么算法”，而是“密钥/IV 是否具备密码学随机性”。哪怕 AES-GCM 写得再规范，IV 复用一次，整个加密就垮掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
