值类型在字段不含可变引用且不依赖跨goroutine同步时更利于安全隔离；传值产生独立副本，避免竞态，但含map、slice等字段仍共享底层数据，需深拷贝或加锁；大结构体或需共享状态时应使用指针。
是的，Go 中的值类型在多数并发场景下天然更利于安全隔离——但这个“利于”有明确前提：字段不含可变引用，且不依赖跨 goroutine 状态同步。
为什么值传递能减少竞态风险
值类型（如 int、string、小 struct）传参或赋值时会完整拷贝，每个 goroutine 拿到的是独立副本。这意味着：
- 无需加锁，多个 goroutine 同时读写各自的副本互不影响
- 不会意外修改其他 goroutine 所见的状态，副作用被天然限制在作用域内
- 配合 channel 传输时，接收方拿到的就是干净快照，适合做任务分发或事件建模
例如用 Config 初始化 worker：
type Config struct {
Timeout time.Duration
Retries int
}
func startWorker(cfg Config) {
// 修改 cfg 不会影响调用方或其他 worker
cfg.Retries++
// ...
}
这里每个 goroutine 的 cfg 都是独立内存，改它等于白改——但这恰恰是优势：你本就不该让 worker 去改全局配置。
立即学习“go语言免费学习笔记（深入）”；
值类型也会引发竞态？关键看字段
结构体是值类型，不代表它“绝对线程安全”。一旦字段含引用类型（[]byte、map[string]int、*sync.Mutex），副本之间仍共享底层数据。
wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support
下载
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
常见错误现象：Tags []string 字段被多个 goroutine 并发 append，导致底层数组重分配时 panic 或数据错乱。
- 问题不在结构体本身，而在其字段的语义：可变引用 = 共享状态
- 解决不是“别用值类型”，而是明确字段意图：若需只读，用
copy或转为不可变切片；若需修改，要么深拷贝（make+copy），要么统一用指针 +sync.RWMutex - 特别注意 JSON 反序列化后字段仍是引用：即使结构体按值传，
json.Unmarshal写入的map或slice仍指向同一堆内存
什么时候必须用指针，而不是迷信“值更安全”
值语义不是银弹。以下场景强行用值类型反而引入 bug 或性能损耗：
- 需要跨 goroutine 更新同一状态：比如计数器
counter，传值后每个 goroutine 自增自己的副本，主 goroutine 根本看不到变化 - 结构体过大（>16 字节常见阈值）：拷贝开销显著，GC 压力上升；此时传
*MyBigStruct更实际 - 方法需修改接收者字段：值接收器
func (u User) SetName()改的是副本，调用后原对象不变——并发中尤其容易误判逻辑是否生效
典型反例：
var wg sync.WaitGroup
var counter int
for i := 0; i < 10; i++ {
wg.Add(1)
go func(c int) { // 错！c 是副本
c++ // 修改无效
wg.Done()
}(counter)
}
wg.Wait()
// counter 还是 0
正确做法是传地址：&counter，并配 sync.Mutex 或 atomic.AddInt64。
最易被忽略的一点：值类型的“安全性”完全依赖字段的不可变性。一个 struct 是否真能当值用，得逐个检查它的每个字段——哪怕只嵌套了一个 map，它就不再是“纯值语义”。
