buffalo 默认不支持 sqlite，因 pop v5+ 移除了 sqlite 官方驱动，导致 buffalo db 命令报“unknown dialect 'sqlite3'”；可靠方案是弃用 pop，改用 database/sql + mattn/go-sqlite3 手动管理连接。
buffalo 默认不原生支持 SQLite，它生成的项目骨架（哪怕加了 --api）默认依赖 pop 迁移工具 + database.yml 配置，而 pop 官方驱动只内置 PostgreSQL、MySQL 和 SQL Server —— SQLite 不在默认支持列表里。直接照搬 Rails 风格配置会失败。
为什么 buffalo new --api 无法直接连 SQLite
buffalo new --api 无法直接连 SQLiteBuffalo 的数据库抽象层 pop 在 v5+ 版本中已移除对 SQLite 的官方维护。你执行 buffalo db create 或 buffalo db migrate 时会报错：unknown dialect "sqlite3" 或 driver: unknown driver "sqlite3" (forgotten import?)。这不是配置写错，是底层缺失注册。
-
pop的dialect注册逻辑硬编码在github.com/gobuffalo/pop/v6的dialects/目录下，SQLite 目录不存在 - 即使手动
import _ "github.com/mattn/go-sqlite3"，pop也缺少对应的SqliteDialect实现 -
database.yml中写development: {dialect: sqlite3, database: ./dev.sqlite}会静默忽略或 panic
绕过 pop：用原生 sql.DB 直连 SQLite
pop：用原生 sql.DB 直连 SQLite最可靠的做法是放弃 pop 迁移和模型层，改用 Go 标准库 database/sql + github.com/mattn/go-sqlite3 手动管理连接。Buffalo 的 app.go 和 actions/ 仍可复用，只需注入一个全局 *sql.DB。
- 在
app.go顶部添加：import ( _ "github.com/mattn/go-sqlite3" "database/sql" )
- 在
app.New()函数内初始化并挂载到App结构体：db, err := sql.Open("sqlite3", "./dev.sqlite") if err != nil { log.Fatal(err) } a.DB = db // 假设你给 App 结构体加了 DB *sql.DB 字段 - 在 handler（如
actions/users.go）中直接用app.DB.QueryRow(...)，无需pop模型
注意：SQLite 文件路径必须是相对或绝对磁盘路径（如
./data/app.db），不能用内存模式（:memory:）—— Buffalo 的热重载会导致连接丢失。
Buffalo框架 1.0.1下载Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
如果坚持用 pop，唯一可行方案是降级 + 补丁
pop，唯一可行方案是降级 + 补丁极少数旧项目（pop v4.x + buffalo v0.16.x）曾实验性支持 SQLite，但已归档且无安全更新。强行复用风险高：
- 需锁定
go.mod中github.com/gobuffalo/pop/v4和github.com/gobuffalo/buffalo到 2021 年前的 commit - 手动 patch
pop/v4/dialects/sqlite3/目录（社区有 fork，但无人维护） -
buffalo dev启动时可能因 Go 1.20+ 的 embed 变更而编译失败
现实建议：别走这条路。SQLite 的轻量优势，在 Buffalo 的全栈包袱下早已被抵消；真要 SQLite，用
gin或纯net/http+mattn/go-sqlite3更干净。
Buffalo 和 SQLite 是错配组合。框架设计初衷是服务 PostgreSQL 场景，它的中间件链、事务上下文、迁移钩子都围绕有完整 ACID 支持的数据库展开。强行嫁接 SQLite，最后往往卡在「迁移跑不通」「测试用内存 DB 但生产切文件路径失败」「并发写入锁死」这些边缘问题上——而这些问题，在选型那一刻就注定了。
