go run main.go 在 Fyne 中大概率失败，因其跳过资源绑定、图标嵌入和清单生成等关键步骤，导致窗口不显示、图标空白或静默退出，且无法正确初始化原生事件循环与上下文。
为什么 go run main.go 在 Fyne 里大概率失败
Fyne 不是纯 Go 实现的 UI 库，它依赖系统原生后端（macOS 的 Cocoa、Windows 的 Win32、Linux 的 X11/Wayland），而 go run 会跳过资源绑定、图标嵌入、清单文件生成等关键步骤，导致窗口不显示、图标空白、甚至静默退出。
- 常见错误现象：
go run main.go后终端一闪而过，没弹窗；或弹窗但标题栏无图标、内容区全黑；Linux 下可能报GLXBadContext -
go run不触发fyne package的资源打包流程，也就不会把icon.png编译进二进制，也不会生成Info.plist（macOS）或manifest（Windows） - 即使界面勉强出来，也大概率无法响应拖拽、缩放、系统菜单等原生行为——因为事件循环和窗口上下文没被正确初始化
app.New() 和 a.NewWindow() 的顺序为什么不能反
Fyne 的生命周期强依赖对象创建顺序：app.New() 初始化全局状态（事件循环、主题管理、剪贴板句柄、资源加载器），之后才能基于这个实例创建窗口；反过来，a.NewWindow() 会 panic 或返回 nil。
- 错误写法：
w := myApp.NewWindow("test")——myApp根本没定义，编译直接报错 - 更隐蔽的错：
app.NewWindow("x")（误用包名app而非实例a）—— 编译通过但运行时 panic: “nil pointer dereference” - 漏掉
a.Run()：程序启动即退出；写成app.MainLoop()会编译失败（该函数不存在）
Linux 下点开二进制没反应或报 GLXBadContext 怎么临时救急
这是 OpenGL 上下文初始化失败，常见于无桌面环境（SSH 登录后直接运行）、Wayland 会话未适配、或缺少 GPU 驱动。生产环境应修复依赖，但开发调试可快速绕过。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 强制指定后端：
GDK_BACKEND=wayland ./myapp或GDK_BACKEND=x11 ./myapp - 启用软件渲染（仅限调试）：
LIBGL_ALWAYS_SOFTWARE=1 ./myapp—— 动画卡顿、性能明显下降，别在正式机器上长期用 - 真正解决方式：确保安装了
libgl1-mesa-dev（Ubuntu/Debian）或mesa-libGL（RHEL/Fedora），且不在 headless 环境中直接双击运行 GUI 二进制
图标、配置、资源怎么才算“正确打包”
Fyne 不接受手动复制图标到目录或硬编码路径；所有资源必须经 fyne bundle 处理并 import，配置文件也得走 app.Storage().RootURI() 读取，否则跨平台时必然失效。
- 图标必须先生成 Go 文件：
fyne bundle -o icon.go icon.png，再import _ "./icon"（路径按实际调整） - 配置文件（如
config.json）不能放在./config/这种相对路径，得存到app.Storage().RootURI()返回的位置，否则 macOS 沙盒或 Windows 安装版里根本打不开 -
fyne package -os linux会自动调用go build，但还会注入图标、设置元数据、打包资源——漏掉这步，Windows 用户双击可能看到“找不到 MSVCP140.dll”，macOS 用户打开提示“已损坏”
最常被忽略的一点：Fyne 的“一次编写，处处运行”是有前提的——你得用它规定的方式构建，而不是把它当成普通 Go 包来 go run 或裸 go build。跨平台不是魔法，是工具链和约定共同守住的边界。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
