sqlc 是開發時執行的命令列工具，不是程式在執行時匯入的函式庫；執行時的程式碼只依賴它產生出來的檔案與 pgx。產生出來的 store 套件放在專案的 Go 模組裡，呼叫端以 import "<go.mod 的 module 名稱>/sqlcdemo/store" 引用。

設定檔與目錄

 1migrations/                 # 專案的 migration 目錄，與 sqlcdemo/ 同一層
 2├── 001_init.up.sql
 3└── 001_init.down.sql
 4sqlcdemo/
 5├── sqlc.yaml
 6├── query/
 7│   └── orders.sql      # 手寫的查詢
 8└── store/              # sqlc 產生，不手動修改
 9    ├── db.go
10    ├── models.go
11    └── orders.sql.go

 1version: "2"
 2sql:
 3  - engine: "postgresql"
 4    schema: "../migrations"   # 建表的 SQL；指向 migration 目錄
 5    queries: "query"          # 手寫查詢所在的目錄
 6    gen:
 7      go:
 8        package: "store"
 9        out: "store"            # 產生的程式碼放哪裡
10        sql_package: "pgx/v5"   # 產生的程式碼呼叫 pgx 的原生介面

不寫 sql_package 時，產生的是呼叫 database/sql 的程式碼。要和 GORM 在同一個交易裡執行就選它，見 10.7 Go 專案的資料庫存取工具選型：GORM、sqlc 與 pgx 的組合〈混用時共用同一個交易〉。

schema 指向專案的 migration 目錄（資料表結構的版本化變更檔，見 Schema Migration），sqlc 依序讀裡面的檔案、算出最終的資料表結構。它認得幾種 migration 工具的檔名慣例，例如 golang-migrate 的 001_init.up.sql 與 001_init.down.sql 放在同一個目錄時，只讀 up 那一份；把 down 也讀進去的話，DROP TABLE 會讓後面的查詢全部找不到表。schema 的權威因此留在 migration，sqlc 只是讀它。

查詢檔與註記

每一段查詢上方的註記（query annotation）決定產生的函式名稱與回傳形狀：

 1-- name: ListOrdersByCustomer :many
 2SELECT id, customer_id, amount, note, ordered_at
 3FROM orders
 4WHERE customer_id = $1
 5ORDER BY id;
 6
 7-- name: GetCustomer :one
 8SELECT id, name, email FROM customers WHERE id = $1;
 9
10-- name: CreateCustomer :one
11INSERT INTO customers (name, email) VALUES ($1, $2)
12RETURNING id, created_at;
13
14-- name: TotalByCustomer :many
15SELECT c.name, sum(o.amount) AS total
16FROM customers c JOIN orders o ON o.customer_id = c.id
17GROUP BY c.name
18ORDER BY c.name;

產生指令在設定檔所在的目錄執行：

1# 不安裝，直接執行指定版本；第一次要下載並編譯，需要一兩分鐘
2go run github.com/sqlc-dev/sqlc/cmd/sqlc@v1.31.1 generate
3
4# 安裝成執行檔之後，每次產生只要不到一秒；執行檔放在 $(go env GOPATH)/bin，那個目錄要在 PATH 裡
5go install github.com/sqlc-dev/sqlc/cmd/sqlc@v1.31.1
6sqlc generate

sqlc v1.31.1 要求 Go 1.26 以上來編譯它自己；手上的 Go 版本較舊時，Go 會依 GOTOOLCHAIN 的預設設定自動下載符合的工具鏈，這不影響專案本身用的 Go 版本。版本號寫在指令裡，團隊每個人產生的程式碼才會一致；產生出來的檔案開頭也會記下產生它的 sqlc 版本。

產生出來的程式碼

ListOrdersByCustomer 產生的函式就是 10.1 database/sql：連線池、查詢結果的讀取與交易 讀多列的標準寫法，只是由工具寫出來：

 1func (q *Queries) ListOrdersByCustomer(ctx context.Context, customerID int64) ([]Order, error) {
 2	rows, err := q.db.Query(ctx, listOrdersByCustomer, customerID)
 3	if err != nil {
 4		return nil, err
 5	}
 6	defer rows.Close()
 7	var items []Order
 8	for rows.Next() {
 9		var i Order
10		if err := rows.Scan(&i.ID, &i.CustomerID, &i.Amount, &i.Note, &i.OrderedAt); err != nil {
11			return nil, err
12		}
13		items = append(items, i)
14	}
15	if err := rows.Err(); err != nil {
16		return nil, err
17	}
18	return items, nil
19}

參數與回傳型別依查詢決定：查詢選的欄位剛好是一整張表時，回傳那張表對應的 struct（Order，定義在 models.go）；選了部分欄位或含運算結果時，另外產生一個 XxxRow struct（TotalByCustomer 回傳 []TotalByCustomerRow，sum(o.amount) 推成 int64）；參數超過一個時產生一個 XxxParams struct（CreateCustomerParams{Name, Email}）。呼叫端的寫法如下：

1pool, err := pgxpool.New(ctx, dsn)
2q := store.New(pool)
3
4orders, err := q.ListOrdersByCustomer(ctx, 1)
5totals, err := q.TotalByCustomer(ctx)

1[{Name:佳穎 Total:800} {Name:宗翰 Total:250}] <nil>

store.New 接受的是 DBTX 這個介面（Exec、Query、QueryRow 三個方法），*pgxpool.Pool 與 pgx.Tx 都符合。交易裡執行時用 q.WithTx(tx) 取得一個綁在那個交易上的 *Queries，交易的開始與收尾仍然照 pgx 那一篇的寫法由程式負責。

產生時擋下的錯誤

sqlc 在產生時解析每一段查詢、對照 schema，欄位或表名寫錯就不產生程式碼。把 GetCustomer 那一行的 name 打成 nmae 再產生一次：

1# package store
2query/orders.sql:8:12: column "nmae" does not exist

同樣的錯字在 sqlx 或 pgx 裡是一個要等到執行那一行才會出現的錯誤。換成 sqlc 之後，schema 改了欄位名稱，重新產生時所有用到舊名稱的查詢一起報錯，連帶呼叫端用到的 struct 欄位也跟著改名，Go 編譯器接著指出每一個要改的呼叫位置。

NULL 與型別對應

pgx v5 的預設對應裡，可以是 NULL 的欄位與 timestamptz 都產生成 pgx 的 pgtype 型別：

1type Order struct {
2	ID         int64
3	CustomerID int64
4	Amount     int32
5	Note       pgtype.Text        // 可以是 NULL 的 text
6	OrderedAt  pgtype.Timestamptz
7}

pgtype 型別讓產生的 struct 依賴 pgx 的套件，放進 domain 型別或 JSON 回應前都要轉換一次。兩個設定改掉這個預設，加在前面 sqlc.yaml 的 gen.go 底下、和 sql_package 同一層：

1gen:
2  go:
3    emit_pointers_for_null_types: true   # 可以是 NULL 的欄位改成指標，例如 *string
4    overrides:
5      - db_type: "timestamptz"
6        go_type: "time.Time"             # NOT NULL 的 timestamptz 對應成 time.Time

1type Order struct {
2	ID         int64
3	CustomerID int64
4	Amount     int32
5	Note       *string
6	OrderedAt  time.Time
7}

依 db_type 寫的 override 預設只套用在 NOT NULL 的欄位；可以是 NULL 的 timestamptz 欄位要另寫一條加上 nullable: true 的 override（例如 go_type: {type: "time.Time", pointer: true}），否則仍然是 pgtype.Timestamptz。

integer 欄位產生的是 int32，因為 PostgreSQL 的 integer 就是 32 位元；要 int64 的話建表時用 bigint，或同樣用 overrides 指定。

選擇性的篩選條件

sqlc 產生的函式裡，SQL 文字在產生時就固定了，「有給最低金額才加這個條件」這類依輸入增減的條件，寫法是把條件寫成「參數是 NULL 時永遠成立」。把下面這段加進 query/orders.sql 再重新產生：

1-- name: SearchOrders :many
2SELECT id, amount FROM orders
3WHERE customer_id = $1
4  AND (sqlc.narg(min_amount)::int IS NULL OR amount >= sqlc.narg(min_amount))
5ORDER BY id;

sqlc.narg 宣告一個可以是 NULL 的具名參數。在開了 emit_pointers_for_null_types 的設定下，產生的參數 struct 裡它是指標（預設是 pgtype.Int4）：

1type SearchOrdersParams struct {
2	CustomerID int64
3	MinAmount  *int32 // nil 代表不篩選
4}

1MinAmount = nil  → [{101 300} {102 500}]
2MinAmount = 400  → [{102 500}]

這個寫法在條件只有兩三個時清楚好讀。條件多到十幾個、排序欄位也由使用者決定時，OR 堆疊的查詢讀起來吃力，資料庫為它選的執行計畫也可能不是最好的；那類查詢交給查詢建構器（Query Builder）或 ORM 的條件串接，和 sqlc 並存（混用的方式見 10.7 Go 專案的資料庫存取工具選型：GORM、sqlc 與 pgx 的組合）。

sqlc 帶進來的工作

sqlc 把 SQL 的錯誤提前到產生時，代價是多了一個產生步驟：

• schema 或查詢改了要重新產生，產生的檔案通常提交進版本控制，審查時看得到產生結果的差異。
• CI 裡跑一次產生，再確認工作目錄沒有差異，可以擋下「改了 SQL 卻忘了重新產生」的提交。
• 產生的程式碼不手動修改；要改行為就改 SQL、設定檔，或在產生的函式外面再包一層。

不想要這個步驟、而查詢以單表增刪查改為主的專案，看的是 10.5 GORM：model、關聯載入與 ORM 送出的 SQL。

Go 資料庫存取工具的生態現況

Go 沒有一個像 Laravel 或 Django 那樣把 ORM、驗證、後台整合在一起的主導框架，資料庫存取是各專案自己挑的。從 GitHub 的星數（2026 年 10 月查詢）看各工具受到的關注：GORM 約四萬，sqlc、sqlx、ent 各約一萬七千到一萬八千多，pgx 約一萬四千。星數量的是關注度，不是採用率；ent 是另一種 ORM，schema 寫成 Go 程式碼、再產生型別安全的查詢 API，同時帶有 ORM 與產生程式碼的性質，本模組不示範。pgx 也是 GORM 的 PostgreSQL 方言套件底下用的驅動，所以用 GORM 的專案同時也在用 pgx。

本模組示範兩種常見的做法：用 GORM 這個關注度最高的 ORM，或用 sqlc 加 pgx 這組「SQL 手寫、工具產生程式碼」的組合。團隊選哪一種，比較的是驅動入口、查詢的形狀、審查要看到什麼、團隊背景與錯誤被發現的時間點。

驅動入口：pgx 原生介面還是 database/sql

這個決定先做，因為它決定後面哪些函式庫用得上：

只要共用連線池、不必共用交易時，主程式可以用 pgxpool，再用 stdlib.OpenDBFromPool(pool) 做出一個共用同一個池的 *sql.DB，交給 GORM（postgres.New(postgres.Config{Conn: sqlDB})）或 sqlx；實測兩者共用之後池裡只開一條連線。migration 工具多半在部署步驟或啟動時另開一個 *sql.DB、跑完就關，不影響主程式選哪個入口。應用程式和 PostgreSQL 之間有一層交易模式的 PgBouncer 時，兩個入口都要另外處理：pgx 不論走哪個入口，預設都會在連線上快取預先解析的查詢，實測會出現 prepared statement "stmtcache_…" already exists (SQLSTATE 42P05)，處理方式見 10.2 pgx：PostgreSQL 驅動的原生介面、連線池與 COPY 大量寫入〈pgx 的語句快取與 PgBouncer 交易模式〉。兩個入口可以在同一個程式裡並存；分別用 sql.Open 與 pgxpool.New 建立時各有一個連線池（連線數要合起來算），而不論池是否共用，交易都不能互通：pgx.Tx 與 *sql.Tx 是兩個不相容的型別，一段要在同一個交易裡完成的寫入，必須全部走同一個入口。

主力工具：GORM 還是 sqlc

1.17 應用程式存取資料庫的工具分層 的選型軸套到這兩個工具上：

團隊背景這一軸的理由在於改 SQL 的位置：用 sqlc 時，送出的 SQL 就是 .sql 檔裡那一段，調執行計畫就是改那一段；用 GORM 時要先把那個查詢改寫成 Raw。熟 SQL 的團隊在前一種位置上工作，習慣 ORM 的團隊在後一種。

表裡沒有 sqlx，因為它和 sqlc 處在同一側（SQL 手寫、審查看得到），差別在檢查的時間點與步驟：sqlx 不需要產生步驟，欄位錯誤到執行時才出現；只連 PostgreSQL 時，pgx 原生介面的 RowToStructByName 提供同樣的對映而不必多一個函式庫。所以 sqlx 的落點是：要走 database/sql（例如和 GORM 共用連線池，或要支援 PostgreSQL 以外的資料庫）、想手寫 SQL、又不想加產生步驟。

不同的軸給出相反的傾向時（例如團隊的背景傾向 GORM、查詢的形狀傾向 sqlc），不必二選一，看下面的混用組合。判錯的代價各軸不同：後台列表有十幾個篩選條件卻全交給 sqlc，每加一個條件就多一組 sqlc.narg ... IS NULL OR，查詢越來越長、執行計畫也可能變差；以報表為主的服務選了 GORM，多數查詢最後寫進 Raw，SQL 回到字串，產生時的檢查與 ORM 的對映兩邊都沒拿到；習慣 ORM 的團隊被要求全用 sqlc，初期每一段增刪查改都要寫 SQL 加註記，交付速度明顯變慢。

Go 專案裡 schema 的權威：migration 檔、GORM model 與 Atlas

1.17 應用程式存取資料庫的工具分層 把「schema 的權威放哪裡」列為選型軸：schema 由 model 定義時傾向 ORM，由 migration 的 SQL 定義時傾向從 SQL 產生程式碼。GORM 本身的 AutoMigrate 不適合正式環境（改名變成新增欄位、沒有變更記錄與退回方法，見 10.5 GORM：model、關聯載入與 ORM 送出的 SQL），所以用 GORM 的專案有兩種做法。一種是同樣用版本化 migration 工具、由手寫的 migration 檔當 schema 的權威，這時這個軸分不開 GORM 與 sqlc。另一種是用 Atlas 的 GORM provider（ariga/atlas-provider-gorm）從 model 算出版本化的 migration 檔，model 仍然是 schema 的權威，產生出來的每一份檔案照樣要審查；這時軸又分得開：model 是權威選 GORM 加 Atlas，migration 的 SQL 是權威選 sqlc。golang-migrate 與 goose 都是依序執行手寫的 SQL 檔；Atlas 另外能比對資料庫現況與期望的 schema、產生差異的 migration，三者在這個用途上擇一即可。

以 migration 檔當權威時，用 GORM 與用 sqlc 的差別落在「model 怎麼跟上 schema」：

• sqlc：讀 migration 目錄產生 struct，schema 改了重新產生，對不上的地方在產生或編譯時報錯。
• GORM：model 是手寫的 struct，schema 改了要手動同步 model，對不上的地方在執行時才出現，而且不一定報錯：欄位從資料表移除之後，讀取送出的是 SELECT *，不會報錯，那個欄位保持零值，寫入時才報錯；資料表多出來的欄位則一律被忽略。

用 GORM 的專案通常靠整合測試補上「model 與 schema 不一致要到執行時才發現」這個缺口：在測試環境依序套用全部 migration，再讓每個 model 實際讀寫一次。

以上都假設 schema 由這個 Go 服務擁有。資料庫被多個服務共用、schema 由另一個服務（例如 Laravel 的 migration）管理時，Go 這一側不跑 migration、也不用 AutoMigrate：sqlc 的 schema 改指向 pg_dump --schema-only 匯出的檔案，GORM 的 model 則靠整合測試對著擁有方建出的 schema 驗證；約束名稱也要照擁有方的命名判讀（Laravel 預設把唯一約束命名成 customers_email_unique）。

常見的混用組合

多數 Go 專案不只用一個工具。三種組合最常見：

混用時共用同一個交易

GORM 與 sqlc 寫在同一個交易裡的前提，是兩者都走 database/sql。sqlc 的設定檔不寫 sql_package（或寫 database/sql）時，產生的 DBTX 介面用的是 ExecContext、QueryContext 這組 database/sql 的方法，*sql.Tx 符合它。GORM 的交易函式裡，tx.Statement.ConnPool 就是那個 *sql.Tx（gorm.Config 開了 PrepareStmt 時不是，下面的型別斷言會 panic）。sqlc 這一側的查詢檔裡有這一段：

1-- name: AddNote :exec
2UPDATE orders SET note = $2 WHERE id = $1;

兩者寫在同一個交易裡：

 1err := db.WithContext(ctx).Transaction(func(tx *gorm.DB) error {
 2	if err := tx.Model(&Order{ID: 103}).Update("amount", 999).Error; err != nil {
 3		return err
 4	}
 5
 6	sqlTx := tx.Statement.ConnPool.(*sql.Tx) // GORM 這個交易底下的 *sql.Tx
 7	q := store.New(sqlTx)                     // sqlc 產生的程式碼跑在同一個交易裡
 8	if err := q.AddNote(ctx, store.AddNoteParams{
 9		ID:   103,
10		Note: sql.NullString{String: "同一個交易", Valid: true},
11	}); err != nil {
12		return err
13	}
14	return errors.New("撤銷") // 回傳錯誤：GORM 與 sqlc 的兩筆修改一起撤銷
15})

1ConnPool is *sql.Tx: true
2tx err: 撤銷 amount: 250 note nil: true

金額仍是原來的 250、備註仍是 NULL，兩邊的修改都被撤銷了。sqlc 改成產生 pgx 原生版本（sql_package: "pgx/v5"）的話，它要的是 pgx.Tx，和 GORM 的 *sql.Tx 接不起來；這時有兩個做法：GORM 與 sqlc 各自開交易，接受它們不在同一個交易裡；或把需要一起成功的寫入全部交給 GORM，或全部交給 sqlc。

讀寫分離：GORM 的 dbresolver 與程式自己持有兩個池

讀取量大到要把查詢分給唯讀副本（replica）時，用 GORM 的專案可以用 GORM 官方維護的 dbresolver 外掛；主力是 sqlc 或 pgx 時沒有這樣的外掛，由程式自己持有兩個池。dbresolver 的路由規則在外掛裡，自己持有兩個池時寫在程式碼上，語言無關的比較見 1.17 應用程式存取資料庫的工具分層〈讀寫分離與多個資料庫：連線的路由由哪一層決定〉。

dbresolver 註冊之後，程式照常呼叫 GORM，外掛依查詢的種類選連線。db 原本用主庫的連線字串開啟；dbresolver 的設定裡另有一個 Sources 欄位可以列主庫，沒有列時主庫就是 db 本身的連線；replicaDSN 換成副本的連線字串，有多個副本就列多個：

1db.Use(dbresolver.Register(dbresolver.Config{
2	Replicas: []gorm.Dialector{postgres.Open(replicaDSN)},
3}))

下面的實測用兩個內容不同的資料庫當主庫與副本（取得套件：go get gorm.io/plugin/dbresolver@v1.6.2）：副本裡每位顧客的名字後面多了「（副本）」，查詢讀到哪一個名字，就知道它被送到哪一邊。

 1var c Customer
 2var name string
 3n := Customer{Name: "新顧客", Email: "new@example.com"}
 4
 5db.First(&c, 1)                                // 一般查詢
 6db.Clauses(dbresolver.Write).First(&c, 1)      // 指定主庫
 7db.Create(&n); db.First(&c, n.ID)              // 剛建立就讀
 8db.Transaction(func(tx *gorm.DB) error { tx.First(&c, 1); return nil })
 9db.Raw("SELECT name FROM customers WHERE id = 1").Scan(&name)
10db.Raw("WITH x AS (SELECT 1) SELECT name FROM customers WHERE id = 1").Scan(&name)

1First                                    "佳穎（副本）"
2Clauses(dbresolver.Write).First          "佳穎"
3Create then First(new id)                id=4 err=record not found
4First inside Transaction                 "佳穎"
5Raw SELECT                               "佳穎（副本）"
6Raw WITH ... SELECT                      "佳穎"

一般查詢送副本、寫入與交易裡的查詢送主庫。剛建立的顧客馬上用 First 讀，查詢送到副本而查不到；真實的副本在複製追上之後就讀得到，所以這種錯誤只在寫入後立刻讀、而且複製剛好落後的時候出現。同一個請求裡寫完就讀的查詢要寫 Clauses(dbresolver.Write)，或整段放進交易；寫完之後由下一個請求讀的路徑（建立後導向詳情頁、改完設定馬上重新載入），dbresolver 不知道上一個請求寫過，要程式自己記住這個使用者剛寫過（例如在 session 記下寫入時間，幾秒內的讀取都加 Clauses(dbresolver.Write)）。Raw 的路由看 SQL 文字：外掛的原始碼只在 SQL 以 SELECT 開頭、結尾不是 FOR UPDATE 時送副本，所以 WITH 開頭的查詢送主庫。

程式自己持有兩個池時，這些規則都寫在程式碼上：sqlc 產生的 New 收一個連線介面（DBTX），連線池與交易都符合它，呼叫端決定傳哪一個。

1primary, _ := pgxpool.New(ctx, primaryDSN) // 主庫
2replica, _ := pgxpool.New(ctx, replicaDSN) // 副本
3
4orders, _ := store.New(replica).ListOrdersByCustomer(ctx, 1) // 可以接受落後的訂單列表
5c, _ := store.New(primary).GetCustomer(ctx, 1)               // 剛寫完就讀的那一筆

store 是 10.4 sqlc：從 SQL 產生型別安全的 Go 程式碼 以 sql_package: "pgx/v5" 產生的套件，ListOrdersByCustomer 與 GetCustomer 是那一篇定義的查詢。每一個查詢送到哪裡都在呼叫的那一行看得到，代價是每個呼叫端都要做這個選擇。主庫與副本各有一個池，連線數要分開算上限；dbresolver 的情形也一樣，db.DB() 只回傳主庫的 *sql.DB，副本的池要用 dbresolver 的 SetMaxOpenConns 這組方法設定。這組方法對主庫與每一個副本設同一個值（設定裡沒有列 Sources 時主庫也包含在內），主庫要另一個上限時，在呼叫 dbresolver 的 SetMaxOpenConns 之後，用 db.DB() 取得的 *sql.DB 重設。

選型結果裡要統一的項目：連線池、例外路徑、migration 工具、錯誤值、NULL、交易傳遞、唯讀副本與記錄

選型的結果不只是一個工具名稱，因為同一個工具兩個開發者各自決定細節時，會在下面這幾處分岔：

• 連線池由哪一段程式建立、上限多少：兩處各建一個池，連線數加倍、各自的上限也就失效（池的設定見 10.1 database/sql：連線池、查詢結果的讀取與交易）。
• 主力工具與例外：一人把報表寫成 GORM 的 Raw、另一人寫成 sqlc，同一類查詢有兩種檢查時間點，例外要寫成規則（例如「報表類查詢放 query/ 用 sqlc」）。
• schema 由哪個 migration 工具管理：一人用 AutoMigrate、另一人寫 migration 檔，schema 會漂移，改名還會留下舊欄（見 10.5 GORM：model、關聯載入與 ORM 送出的 SQL〈AutoMigrate 在正式環境的限制〉）。
• 唯一約束的錯誤怎麼判讀：一人讀錯誤代碼、另一人讀約束名稱，回報給使用者的訊息就不一致（見 10.2 pgx：PostgreSQL 驅動的原生介面、連線池與 COPY 大量寫入〈錯誤：*pgconn.PgError〉）。
• 前面有沒有交易模式的連線池代理，以及驅動的查詢執行模式：一人在本機直連 PostgreSQL、另一人在正式環境經過 PgBouncer，預先解析查詢的錯誤只在經過 PgBouncer 的正式環境出現（見 10.2 pgx：PostgreSQL 驅動的原生介面、連線池與 COPY 大量寫入）。
• 主力是 GORM 時，開發與測試環境的兩種記錄：GORM 的 SQL 記錄看得到送出的語句，零值更新被略過時那裡會少一行 UPDATE；預設交易的 begin 與 commit 只在資料庫的語句記錄（log_statement）裡看得到。
• NULL 的表示：sql.NullString、*string 與 sqlc 預設的 pgtype.Text 混在同一個專案裡，轉成 domain 型別的程式就要寫三套（見 10.1 database/sql：連線池、查詢結果的讀取與交易〈Scan 與 NULL〉）。
• 「找不到」的錯誤值：sql.ErrNoRows、pgx.ErrNoRows、gorm.ErrRecordNotFound，以及 GORM 的 Find 不回錯誤；混用的專案三種都會出現，repository 要在邊界把它們轉成同一個錯誤。
• 交易物件怎麼傳進各個 repository：一人用參數傳 *sql.Tx、另一人放進 context，混用時就接不起來（傳遞方式見 1.4 Repository Adapter 實作〈Transaction 傳遞〉，誤用時的徵兆見 Transaction Propagation）。
• 要不要用 gorm.Model 的軟刪除、Save 用在哪裡：一人用軟刪除、另一人寫的報表 SQL 不加 deleted_at IS NULL，或一人用 Save 寫回整列、另一人只改欄位，同一張表上就會出現已刪除的資料被算進報表、別人的修改被蓋掉（見 10.6 GORM 的 gorm.Model、軟刪除與 Save：慣例欄位加上的查詢條件與整列寫回）。
• 有唯讀副本時，哪些路徑強制讀主庫：寫入後立刻讀的路徑一人加了 Clauses(dbresolver.Write)、另一人沒加，同一類畫面時好時壞，只在複製落後時出錯（見〈讀寫分離：GORM 的 dbresolver 與程式自己持有兩個池〉）。
• gorm.Config 的旗標由同一處設定：PrepareStmt、SkipDefaultTransaction、TranslateError 都會改變行為；開了 PrepareStmt，〈混用時共用同一個交易〉的 ConnPool.(*sql.Tx) 型別斷言會 panic。

這幾條決定了 repository 背後的 adapter 長什麼樣；adapter 對上層暴露的 port 怎麼切，見 6.6 如何新增 repository port。