NewPrinter 应返回 Printer 接口而非具体类型，避免调用方导入实现包、进行脆弱类型断言，并支持后续扩展；工厂与接口需同包，用自定义类型替代字符串参数，方法设计应聚焦单一能力、参数由调用方控制。
为什么 NewPrinter 不该返回具体类型
工厂函数如果直接返回 *PdfPrinter 或 *TextPrinter，调用方就不得不 import 具体实现包，还可能写 if p, ok := printer.(*PdfPrinter) 这种脆弱判断。接口抽象失效，后续加 *HtmlPrinter 就得改所有调用点。
正确做法是让工厂只暴露接口，隐藏实现：
type Printer interface {
Print(string) error
}
func NewPrinter(kind string) Printer {
switch kind {
case "pdf":
return &PdfPrinter{} // 返回指针，但类型是 Printer
case "text":
return &TextPrinter{}
default:
return &TextPrinter{}
}
}
-
NewPrinter的返回类型必须是Printer接口，不是任何结构体指针 - 各实现类型（如
PdfPrinter）要显式实现Print方法，否则编译报错：cannot use &PdfPrinter{} as Printer - 别在工厂里 new 后再强转——
return (*PdfPrinter)(nil)是错的，Go 不支持运行时类型转换
如何避免工厂逻辑散落在多个文件里
常见错误是把 NewPrinter 放在 main.go，而 PdfPrinter 定义在 pdf/print.go，导致 main 包依赖所有实现包，破坏解耦。
把工厂和接口定义收拢到一个包里，实现包只依赖接口包：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// printer/printer.go
package printer
type Printer interface { ... }
func NewPrinter(kind string) Printer { ... }
// pdf/pdf.go
package pdf
import "yourapp/printer"
type PdfPrinter struct{}
func (p *PdfPrinter) Print(s string) error { ... }
// 注意：这里不 import main，也不 export NewPdfPrinter
- 实现包（如
pdf）不能导出构造函数，只暴露满足Printer的类型 - 工厂函数
NewPrinter必须和Printer接口在同一个包，否则调用方仍需 import 实现包来断言类型 - 如果实现类型带依赖（如
*http.Client），工厂函数应接受参数，而不是在内部 new —— 否则无法测试或替换依赖
字符串参数 kind 为什么容易出错
用字符串做类型分发，拼错、大小写不一致、多空格都会导致默认分支或 panic。比如传 "PDF" 却只匹配 "pdf"，结果默默用 TextPrinter 打印 PDF 内容，问题延迟暴露。
更安全的方式是用自定义类型约束输入：
type PrinterType string
const (
PdfPrinterType PrinterType = "pdf"
TextPrinterType PrinterType = "text"
)
func NewPrinter(kind PrinterType) Printer {
switch kind {
case PdfPrinterType:
return &PdfPrinter{}
case TextPrinterType:
return &TextPrinter{}
default:
panic("unknown printer type: " + string(kind))
}
}
- 调用方只能用预定义常量：
printer.NewPrinter(printer.PdfPrinterType)，IDE 能自动补全，拼写错误编译即报 - 保留字符串 fallback 的场景（如配置文件读取）可加一层转换函数，但工厂内部仍用类型匹配
- 别为了“灵活”在 switch 里写正则或 substring 判断——简单工厂本就不处理动态扩展，那是抽象工厂或插件系统的职责
接口方法设计不当会拖垮整个工厂
如果 Printer.Print 方法签名是 Print(*bytes.Buffer, string) error，那 PdfPrinter 就得自己处理 buffer 生命周期；如果改成 Print(io.Writer, string) error，又会让 TextPrinter 多一层 os.Stdout 传参，调用变重。
核心原则：接口方法参数应由调用方控制，而非被工厂绑定：
- 避免接收指针或结构体作为参数（如
*Config），否则每个实现都要解析同一份配置，违背解耦初衷 - 优先用 Go 标准库接口（如
io.Writer）作为参数，但注意：如果所有实现都只写文件，那就该让工厂返回io.Writer，而不是另造Printer接口 - 方法名别用
CreateBuildGenerate——这些词暗示副作用或状态变更；PrintSendSave更贴近真实行为
工厂模式的边界很窄：它只解决“根据输入创建某类对象”的问题。一旦开始在接口里塞 Configure、Validate、Close，就说明这个接口已经不是“能力契约”，而是“生命周期契约”了——这时候该考虑组合或拆分接口，而不是硬塞进工厂。
