应使用 rand.intn(len(quotes)) 生成合法索引，避免 rand.int()%len(quotes) 的低位偏差；必须初始化 seed，推荐用 rand.new(rand.newsource(time.now().unixnano()))；名言用切片而非数组，访问前检查非空，并发时每个 goroutine 需独立 rand.rand 实例。
Go 里用 rand.Intn 取随机索引，别直接用 rand.Int
数组随机访问的核心就是生成一个合法下标，rand.Intn(n) 是唯一该用的函数。它返回 [0, n) 范围内的整数，和切片长度天然匹配；而 rand.Int 返回的是大整数，不加模运算会越界或分布不均。
常见错误是写成 rand.Int() % len(quotes) —— 这会导致低位偏差（尤其当 len(quotes) 不是 2 的幂时），而且没初始化 seed 会让每次运行都输出同一句。
- 必须在程序开头调用
rand.Seed(time.Now().UnixNano())，Go 1.20+ 推荐改用rand.New(rand.NewSource(time.Now().UnixNano()))避免全局状态污染 - 如果名言列表固定且不常变，把
*rand.Rand实例缓存为包级变量，避免重复创建 - 不要在 goroutine 里反复调用
rand.Seed，会导致种子碰撞、随机性坍塌
名言数据用 slice 而不是 array，别写死长度
Go 中 [5]string 是数组类型，长度不可变、传参会复制整个底层数组；而 []string 是切片，轻量、可动态增删、底层共享数据。生成器要支持后续加新名言，必须用切片。
错误示范：var quotes [3]string = [3]string{"...", "...", "..."} —— 看似简洁，但想追加就得重构，还容易误用 len(quotes) 当作可变长度依据（其实它是常量）。
立即学习“go语言免费学习笔记（深入）”；
- 定义直接写
quotes := []string{"海内存知己", "山高水长", "人生自古谁无死"} - 如果数据来自文件或配置，用
append动态构建切片，别预分配错误容量 - 访问前务必检查
len(quotes) == 0，空切片下rand.Intn(0)会 panic：「invalid argument to Intn」
并发安全：多个 goroutine 同时调用时，别共用同一个 rand.Rand
如果你的生成器被包装成 HTTP handler 或 CLI 子命令，并发请求进来时，若所有协程共享一个 rand.Rand 实例，会出现随机数序列错乱、重复率异常升高——因为 rand.Rand 的内部状态不是原子更新的。
典型现象：压测时连续几秒返回同一句名言，或者固定周期循环输出。
- 每个 goroutine 应持有独立的
rand.Rand实例，可通过参数传入，或用sync.Pool复用 - 绝不使用全局
rand.*函数（如rand.Intn），它们背后依赖全局rand.Rand，天生不安全 - 如果只是简单命令行工具，单协程场景，用包级
rand.Rand没问题，但得明确知道边界在哪
性能提示：小数据量别上 shuffle，Intn 就够了
有人看到“随机”就本能想 rand.Shuffle 整个切片再取首项——这在名言数超百条时才有意义。对于几十条的静态列表，shuffle 开销远大于一次取模：它要遍历全部元素并做多次 swap。
更隐蔽的问题是，shuffle 后不重置切片，下次调用又 shuffle，等于反复打乱同一份数据，实际随机性反而下降。
- 只取一句？用
r.Intn(len(quotes))+ 下标访问，O(1) - 要连续取多句且不重复？才考虑 shuffle，或维护已用索引集合
- 如果名言来自网络 API，注意别把随机逻辑和 HTTP 调用耦合在一起，先取数据再随机，避免失败时无法 fallback
真正麻烦的从来不是怎么选下标，而是名言来源是否可靠、编码是否一致、有没有隐藏的 BOM 或换行符导致 strings.TrimSpace 漏处理——这些细节比随机算法更容易让程序在线上吐出奇怪的空白名言。
