Colly比原生net/http+goquery快，因其内置调度器、并发控制、去重缓存和响应中间件，且默认复用连接池、遵守robots.txt、按域名限速、DOM解析前过滤URL，避免无效下载与空解析。
Colly为什么比原生net/http+goquery快
Colly不是单纯封装了net/http和goquery，它内置了请求调度器、并发控制、去重缓存和响应中间件链。真正提速的关键是：默认启用连接池复用、自动管理robots.txt遵守策略、支持基于域名的请求限速（而非全局sleep），且DOM解析前就完成URL过滤——避免无效HTML下载。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
c.Limit(&colly.LimitRule{DomainGlob: "*", Parallelism: 4})代替time.Sleep，避免阻塞整个爬虫 - 禁用
robots.txt检查仅在测试环境加c.IgnoreRobotsTxt = true，生产环境别关，否则可能被封IP - DOM解析前用
c.OnHTML的selector匹配失败时，不会触发回调——这省掉了大量空解析开销
如何防止被反爬识别为Colly
默认User-Agent是colly - https://github.com/gocolly/colly，多数WAF会直接拦截。必须覆盖，但不能简单设成Chrome UA——高频请求下仍会被行为分析识别。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次请求随机UA：用
userAgents := []string{"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", ...}+rand.Intn(len(userAgents)) - 加Referer和Accept-Language头：
c.OnRequest(func(r *colly.Request) { r.Headers.Set("Referer", "https://www.google.com/") }) - 关键：禁用
c.WithTransport(&http.Transport{...})里默认的DisableKeepAlives: true——保持长连接反而更像真实浏览器
处理JavaScript渲染页面的边界方案
Colly本身不执行JS，遇到SPA或动态加载内容会漏数据。强行集成Puppeteer或Playwright会破坏Colly的轻量优势，也大幅增加内存占用。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
curl -sI URL | grep "content-type"确认是否返回text/html——如果是application/json，说明API可直取，绕过前端渲染 - 检查页面源码是否存在
window.__INITIAL_STATE__或类似script标签，提取JSON数据比启动浏览器快10倍 - 真需JS执行时，只对特定URL启用Headless Chrome，用
chromedp单独跑，结果通过channel传回Colly主流程，不要混在同一goroutine
并发写入数据库导致的panic和脏数据
常见错误是多个goroutine同时调用db.Exec插入，没加锁也没用连接池，轻则sql: connection is already closed，重则MySQL报Lock wait timeout exceeded。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Pool缓存sql.Rows或结构体，别在OnHTML里反复make([]byte, 1024) - 批量插入用
INSERT INTO ... VALUES (...), (...), (...)，单条INSERT在高并发下IO放大严重 - 数据库连接池设置：
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(10)，数值按Colly并发数*1.5估算，别设成0或1000
Colly的高性能依赖于“不做多余事”——它不帮你处理JS、不自动重试失败请求、也不管你数据库怎么连。越想让它干更多，越容易掉进自己挖的坑。
