Go x/image/font/opentype 创建多个 Face 为什么需要分别管理资源

我在同一个服务里同时支持标题和正文两种字号时，最容易犯的错是把 *opentype.Font 当成“所有绘制请求都能直接共用的渲染器”。实际上，Font 是解析后的字体对象，NewFace 会根据字号、DPI 和 Hinting 创建具体的 font.Face。多个 Face 既要分别管理，也不能把同一个 Face 当成并发安全对象。

官方地址：https://pkg.go.dev/golang.org/x/image/font/opentype

实用结论：字体源数据和解析后的 Font 可以作为共享只读基础；每种渲染配置创建自己的 Face，谁创建谁负责 Close。若多个 goroutine 同时绘制，就让每个任务持有独立 Face，或在更高层为同一个 Face 加互斥保护。

先把 Font、Face 和字体源数据分开

opentype.Parse 负责把 TTF/OTF 字节解析成 *opentype.Font，opentype.NewFace 再从这个 Font 创建实现了 font.Face 的对象。两者的职责不同：Font 代表字体文件的解析结果，Face 代表某组具体的字号、DPI 和 Hinting 配置。

因此，“创建多个 Face”并不是重复解析字体，也不应该把它们塞进一个没有所有权规则的共享字段。每次 NewFace 成功后，都要记录对应的 Close 责任；某个 Face 关闭，不应顺手把仍在使用的其他 Face 一起当成无效对象。

不同配置应该对应不同 Face

FaceOptions 里最直接的三个配置是 Size、DPI 和 Hinting。标题需要 24 点、正文需要 14 点时，创建两个 Face 比在同一个 Face 上反复改状态更清晰，也更容易判断谁负责释放。

package main

import (
    "fmt"

    "golang.org/x/image/font"
    "golang.org/x/image/font/gofont/goregular"
    "golang.org/x/image/font/opentype"
)

func newFaces() (font.Face, font.Face, error) {
    parsed, err := opentype.Parse(goregular.TTF)
    if err != nil {
        // 字体源解析失败时，不应继续创建任何 Face。
        return nil, nil, fmt.Errorf("解析字体：%w", err)
    }

    titleFace, err := opentype.NewFace(parsed, &opentype.FaceOptions{
        Size:    24,
        DPI:     72,
        Hinting: font.HintingFull,
    })
    if err != nil {
        // 标题 Face 创建失败时，正文 Face 尚未创建，直接返回错误。
        return nil, nil, fmt.Errorf("创建标题 Face：%w", err)
    }

    bodyFace, err := opentype.NewFace(parsed, &opentype.FaceOptions{
        Size:    14,
        DPI:     72,
        Hinting: font.HintingNone,
    })
    if err != nil {
        // 已经成功创建的 Face 必须在错误路径中释放。
        _ = titleFace.Close()
        return nil, nil, fmt.Errorf("创建正文 Face：%w", err)
    }
    return titleFace, bodyFace, nil
}

这段代码里两个 Face 共享同一个解析结果，但配置和关闭责任是分开的。实际项目还应保留字体源字节的只读生命周期：只要 Font 或它派生的 Face 仍可能被使用，就不要修改或提前释放底层数据。

并发时不要直接复用同一个 Face

官方文档明确说明 opentype.Face 不是并发安全的。这个限制和 Font 能否共享是两件事：共享 Font 只表示多个 Face 可以从同一个解析结果创建，不能推出同一个 Face 可以被多个 goroutine 同时调用。

func renderInParallel(parsed *opentype.Font) error {
    var err error

    titleFace, err := opentype.NewFace(parsed, &opentype.FaceOptions{Size: 24, DPI: 72})
    if err != nil {
        // 创建失败立即返回，避免向并发任务传入空 Face。
        return err
    }
    defer titleFace.Close()

    bodyFace, err := opentype.NewFace(parsed, &opentype.FaceOptions{Size: 14, DPI: 72})
    if err != nil {
        // titleFace 已由 defer 接管，错误路径不会泄漏它。
        return err
    }
    defer bodyFace.Close()

    // 每个任务只接触自己的 Face；不要把 titleFace 传给多个 goroutine。
    go renderTitle(titleFace)
    go renderBody(bodyFace)
    return nil
}

func renderTitle(face font.Face) { /* 说明：标题任务独占一个 Face。 */ }
func renderBody(face font.Face)  { /* 说明：正文任务独占另一个 Face。 */ }

示例只表达资源分工，真实代码还要用 sync.WaitGroup 或其他同步方式等待任务完成，再离开 renderInParallel。否则函数返回后，defer Close 可能先执行，后台 goroutine 仍在使用 Face 就会形成生命周期错误。

用统一清理边界管理多个 Face

当 Face 数量继续增加时，建议把创建和释放放进一个小型管理结构，而不是把 Close 分散到很多调用方。最重要的顺序是：确认所有使用者已经结束，再逐个关闭；清理函数要能处理部分创建成功、部分创建失败的情况。

type FaceSet struct {
    Title font.Face
    Body  font.Face
}

func (s *FaceSet) Close() error {
    // 先关正文再关标题，两个 Face 的释放互不替代。
    var firstErr error
    if s.Body != nil {
        if err := s.Body.Close(); err != nil && firstErr == nil {
            firstErr = err
        }
    }
    if s.Title != nil {
        if err := s.Title.Close(); err != nil && firstErr == nil {
            firstErr = err
        }
    }
    return firstErr
}

如果业务确实只能共享一个 Face，就把并发保护放在 Face 外面，例如用互斥锁包住完整的绘制操作；不要只锁住某个指标调用，却让同一个 Face 在其他路径继续被并发访问。多数情况下，为不同任务创建独立 Face 更容易维护。

创建前后的资源边界速查

我的经验是：把 Font 视为共享的只读基础，把 Face 视为带生命周期的工作对象。这样创建多个 Face 时，资源管理、并发分工和错误回收都能落在同一条规则上。

相关问题

多个 Face 可以共享同一个 Font 吗？

可以。NewFace 的输入就是同一个 Font，但每个 Face 的配置和 Close 责任仍然独立。

同一个 Face 能不能加锁后复用？

可以把互斥锁放在 Face 的所有使用入口外层，保证一次只有一个调用；如果任务天然并发，创建多个 Face 通常更直观。

为什么只关闭一个 Face 不够？

因为 NewFace 创建的是多个独立对象。关闭其中一个不会替代其他 Face 的清理，管理结构应保存并逐个释放每个成功创建的 Face。