golang

Go Modules：现代化的依赖管理

全面讲解 Go Modules 官方依赖管理方案，从 GOPATH 时代的痛点讲起，涵盖模块初始化、go.mod 与 go.sum 文件结构、自动与手动添加依赖、语义化版本与 MVS 算法、升级降级、replace 指令、私有模块配置、Vendor 模式、Workspace 工作区，以及企业级项目中的最佳实践、常见问题解答和项目实战案例。

Leeting Yan 12 分钟阅读 5962 字

Go Modules：现代化的依赖管理

在 Go 1.11 之前，Go 的依赖管理一直是个痛点。所有的代码都要放在 GOPATH 下，版本号管理很麻烦，同一个包的不同版本不能共存。社区出现了很多第三方工具——glide、dep、govendor——但每个都有自己的问题，导致生态分裂、学习成本高昂。

Go 1.11 引入了 Go Modules，这是 Go 官方的依赖管理方案。它让你可以在任何目录下创建项目，精确管理依赖版本，还支持可重复构建。到 Go 1.16，Go Modules 已经成为默认的依赖管理方式，彻底取代了 GOPATH 模式的旧时代。

今天我们就来全面学习 Go Modules，让你能自信地管理任何 Go 项目的依赖，从个人项目到企业级微服务架构。

GOPATH 时代的痛点

在 Go Modules 出现之前，Go 项目必须放在 GOPATH/src 目录下。这种设计带来了诸多不便：

  • 目录限制：所有项目代码都要放在 $GOPATH/src 下，无法自由选择项目位置
  • 版本管理困难：没有内置的版本管理方案，同一包的多个版本无法共存
  • 外部工具依赖：需要使用 glide、dep、govendor 等第三方工具，工具之间互不兼容
  • 可重复构建问题：不同开发者的依赖版本可能不同，导致"在我的机器上可以跑"的问题

Go Modules 优雅地解决了这些问题，它是 Go 生态走向成熟的重要标志。

什么是 Go Module？

一个 Module 就是一组相关的 Go 包，它们作为一个整体被版本化和分发。每个 module 都有一个唯一的模块路径（module path）和版本号（version）。

// go.mod
module github.com/yourname/myproject

go 1.22

模块路径就是模块的"名字"，通常是一个 URL 形式的字符串，用来唯一标识这个模块。版本号遵循语义化版本规范（SemVer），格式为 vMAJOR.MINOR.PATCH。模块的定义文件 go.mod 是项目依赖管理的核心。

Go Modules 的最大优势在于：模块可以位于文件系统的任何位置，不再受 GOPATH 的约束。每个模块的依赖信息都是自包含的，通过 go.mod 和 go.sum 两个文件精确描述。

初始化模块

用 go mod init 创建一个新的模块，这是开始一个新 Go 项目的标准第一步：

$ mkdir myproject
$ cd myproject
$ go mod init github.com/yourname/myproject
go: creating new go.mod: module github.com/yourname/myproject

这会在当前目录下创建一个 go.mod 文件：

module github.com/yourname/myproject

go 1.22

go.mod 文件是模块的核心。它声明了：

  1. 模块路径（第一行）：模块的唯一标识符，通常使用代码仓库地址
  2. Go 版本要求：指定项目需要的最低 Go 版本
  3. 依赖列表：通过 require、replace、exclude 等指令管理

假设我们在企业环境中开发，完整的 go.mod 初始化流程会如下：

# 在企业内部 GitLab 上创建项目
git clone git@gitlab.company.com:backend/userservice.git
cd userservice

# 根据公司规范初始化模块
go mod init gitlab.company.com/backend/userservice

# 验证 go.mod 是否创建成功
cat go.mod
# Output: module gitlab.company.com/backend/userservice
#         go 1.22

添加依赖

自动添加

当你 import 一个包然后运行 go build 或 go run 时，Go 会自动下载依赖并更新 go.mod：

// main.go
package main

import (
	"fmt"
	"github.com/fatih/color"
)

func main() {
	color.Green("Hello, Go Modules!")
	fmt.Println("依赖管理如此简单")
}

$ go run main.go
go: finding module for package github.com/fatih/color
go: found github.com/fatih/color in github.com/fatih/color v1.10.0
Hello, Go Modules!
依赖管理如此简单

查看更新后的 go.mod：

module github.com/yourname/myproject

go 1.22

require github.com/fatih/color v1.10.0

与此同步生成的还有一个新文件 go.sum，它记录了所有依赖的校验和（checksum），确保构建的可重复性，防止供应链攻击。

github.com/fatih/color v1.10.0 h1:7dTwLe9MkiA1R8E3YQ5zqAa9c5mD3sT4uL5nX6pQ7r=
github.com/fatih/color v1.10.0/go.mod h1:abcd1234abcd1234abcd1234abcd1234abcd1234=
github.com/mattn/go-colorable v0.1.8 h1:c1ghPdcGhI/Sl8HrcOX5Tx8fJY7eN4gJ8jDXg4J/4...
github.com/mattn/go-colorable v0.1.8/go.mod h1:h409h5v4fsY4jqIfgRMy8Ie/...

每个依赖都有两行：第一行是内容哈希（用于验证下载的文件），第二行是 go.mod 文件的哈希（用于验证模块元数据）。这种双重校验机制确保了依赖的完整性和安全性。

手动添加

用 go get 可以显式添加或更新依赖：

# 添加最新版本
go get github.com/gin-gonic/gin

# 添加特定版本
go get github.com/gin-gonic/gin@v1.7.0

# 添加特定分支
go get github.com/gin-gonic/gin@main

# 添加特定 commit
go get github.com/gin-gonic/gin@a1b2c3d

# 添加次要版本或补丁版本的最小版本
go get github.com/gin-gonic/gin@latest
go get github.com/gin-gonic/gin@patch

在企业开发中，建议始终使用精确版本号，避免使用 latest 标签，因为这会导致构建的非确定性：

# 生产环境中推荐的做法
go get github.com/gin-gonic/gin@v1.9.1

# 查看依赖是否会成功编译
go mod download
go build ./...

go.sum 文件

go.sum 的结构值得仔细理解：

github.com/fatih/color v1.10.0 h1:7dTwLe9MkiA1R8E3YQ5zqAa9c5mD3sT4uL5nX6pQ7r=
github.com/fatih/color v1.10.0/go.mod h1:abcd1234abcd1234abcd1234abcd1234abcd1234=

每行包含：

  • 模块路径
  • 版本号
  • 前缀 h1: 表示 SHA-256 哈希算法
  • 校验和值（经过 base64 编码）

go.sum 的作用是确保构建的可重复性。即使远程仓库的内容被篡改，Go 也能通过校验和检测出来。这是一个重要的安全防线，防止恶意依赖替换。

⚠️ 重要：go.sum 应该提交到版本控制中。没有它，别人拉取你的代码后构建结果可能和你的不一样，也可能触发安全警告。

常用命令详解

依赖查询与管理

# 查看当前模块的依赖列表（直接和间接）
go list -m all

# 查看某个特定依赖的版本信息
go list -m github.com/gin-gonic/gin

# 查看所有可用的版本
go list -m -versions github.com/gin-gonic/gin

# 查看依赖树，了解间接依赖关系
go mod graph

# 查看为什么依赖某个包（追溯依赖来源）
go mod why github.com/some/package
go mod why -m github.com/some/package

# 查看过时的依赖（需要更新）
go list -m -u all
go list -m -u github.com/gin-gonic/gin

go mod tidy

这是最常用的命令之一。它会：

  1. 分析代码中实际 import 的包
  2. 添加缺失的依赖到 go.mod
  3. 删除不再使用的依赖（清理无用依赖）
  4. 整理 go.mod 文件内容
  5. 确保 go.sum 文件与 go.mod 一致
go mod tidy

💡 最佳实践：每次修改依赖后都运行一次 go mod tidy，确保文件的整洁和一致性。建议在 CI/CD 流程中加上检查：

# CI 中检查 go.mod 是否整洁
if [ "$(go mod tidy; git diff go.mod go.sum | wc -l)" -gt 0 ]; then
    echo "go.mod 或 go.sum 有变更，请运行 go mod tidy 并提交"
    exit 1
fi

go mod download

# 下载所有依赖到本地缓存
# 本地缓存位置：$GOPATH/pkg/mod
go mod download

# 下载特定依赖
go mod download github.com/gin-gonic/gin@v1.7.0

这在构建镜像、CI 环境准备时非常有用。Dockerfile 中常用的多阶段构建模式会利用这个命令：

FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o myapp .

go mod vendor

Vendor 模式会把所有依赖复制到项目的 vendor/ 目录下：

go mod vendor

好处：

  • 构建不依赖网络，适合离线环境或安全限制严格的企业
  • 依赖代码可见，便于审计和安全审查
  • 保证构建的可重复性，即使依赖源不可用也能构建

缺点：

  • 项目体积变大（vendor/ 目录通常较大）
  • 需要手动同步，每次更新依赖后需要重新运行 go mod vendor

Go 1.14 后，如果项目根目录有 vendor/，默认就会使用它构建。

# 验证 vendor 是否完整
go mod verify

# 清理未使用的缓存
go clean -modcache

版本管理

语义化版本（SemVer）

Go Modules 使用语义化版本（Semantic Versioning，SemVer）。版本号格式是 vMAJOR.MINOR.PATCH：

  • MAJOR：主版本号，不兼容的 API 变更
  • MINOR：次版本号，向后兼容的功能新增
  • PATCH：补丁版本号，向后兼容的 bug 修复

例如 v1.7.0 表示主版本 1，次版本 7，补丁版本 0。

最小版本选择（MVS）

Go 有一个独特的版本选择算法叫做 Minimum Version Selection（MVS）。简单来说：

对于每个依赖，Go 会选择所有依赖关系中要求的最小版本中的最大者。

这听起来有点绕，举个例子：

  • 模块 A 要求 foo v1.2.0
  • 模块 B 要求 foo v1.3.0
  • 那么最终使用 foo v1.3.0

这和 npm、pip 等工具的行为不同。MVS 的好处是可预测性强——你看到的 go.mod 里的版本，就是实际使用的版本（除非有间接依赖要求更高版本）。你不需要担心隐式的版本升级或冲突。

版本约束

Go Modules 的 require 部分不支持像 npm 那样的版本范围（比如 ^1.2.0、~1.2.0）。你只能指定一个精确的版本：

require github.com/gin-gonic/gin v1.7.0

如果你想升级到更高的版本，用 go get：

go get github.com/gin-gonic/gin@v1.8.0

这种设计虽然缺少了一些灵活性，但换来了确定性和可预测性——你永远不会因为版本约束的模糊理解而踩坑。

升级和降级依赖

升级依赖

# 升级到最新版本
go get -u github.com/gin-gonic/gin

# 升级到最新的补丁版本（不升级主版本）
go get -u=patch github.com/gin-gonic/gin

# 升级所有依赖
go get -u ./...
go get -u=patch ./...

# 降级到特定版本
go get github.com/gin-sonic/gin@v1.6.0

查看过时的依赖

$ go list -m -u all
github.com/yourname/myproject
github.com/fatih/color v1.10.0 [v1.12.0]
github.com/gin-gonic/gin v1.6.0 [v1.7.0]

方括号里是最新可用版本。这能帮助你及时跟进安全补丁和功能更新。

检查依赖许可证

在企业合规环境中，常常需要检查依赖的许可证：

# 使用第三方工具检查许可证
go install github.com/google/go-licenses@latest
go-licenses check github.com/yourname/myproject

# 生成 CSV 格式的许可证报告
go-licenses csv github.com/yourname/myproject > licenses.csv

replace 指令

有时候你需要用一个本地路径或者 fork 版本替换某个依赖：

module github.com/yourname/myproject

go 1.22

require github.com/some/package v1.0.0

replace github.com/some/package => ../local/package

或者替换成另一个远程仓库：

replace github.com/some/package => github.com/yourname/package v1.0.1

常见用法：

  1. 本地开发：同时修改多个模块，不需要发布到远程
  2. 使用 fork 版本：原仓库有问题，你 fork 了一个修复版本
  3. 解决版本冲突：强制使用某个特定版本
  4. 私有仓库替代：将公开的依赖替换为内部维护的分支

⚠️ 注意：replace 只对主模块生效，对其他依赖你的模块不生效。所以发布前应该尽量去掉 replace。

典型的本地开发 replace 场景：

module github.com/company/apiserver

go 1.22

require (
    github.com/company/common-lib v0.3.0
    github.com/gin-gonic/gin v1.9.1
)

// 本地开发时使用本地的 common-lib
replace github.com/company/common-lib => ../common-lib

exclude 指令

当你发现某个版本的依赖有严重 bug 或安全漏洞时，可以使用 exclude 指令排除它：

module github.com/yourname/myproject

go 1.22

exclude github.com/some/package v1.2.0

require github.com/some/package v1.3.0

这会让 Go 在依赖解析时跳过 v1.2.0，自动选择下一个可用的版本。

发布模块

当你的模块准备好给别人使用时，需要做以下事情：

1. 确定版本号

第一个正式版本应该是 v1.0.0。在此之前，可以用 v0.x.x 或 v1.0.0-rc1 这样的预发布版本。v0.x 版本在语义化版本规范中意味着"不保证向后兼容"，适合还在快速迭代的项目。

2. 打 Git 标签

git tag v1.0.0
git push origin v1.0.0

Go 工具链会根据 Git 标签确定模块的版本。标签必须精确匹配 SemVer 格式（加 v 前缀）。

3. 验证模块

# 检查模块能否被正确下载
go mod download github.com/yourname/myproject

# 用 go vet 检查代码
go vet ./...

# 运行单元测试
go test ./...

# 检查模块是否有问题（Go 官方模态检查工具）
go mod tidy && git diff --exit-code

v2 及以上版本

按照语义化版本规则，主版本号 >= 2 时，需要在模块路径后加 /v2：

module github.com/yourname/myproject/v2

go 1.22

这叫做"主要版本后缀"（Major Version Suffix），让 v1 和 v2 可以在同一个项目中共存而不冲突。这是 Go Modules 设计的一大亮点——不同主版本被视为完全不同的模块。

# 升级主版本时的开发流程
git checkout -b v2
# 修改 go.mod: module github.com/yourname/myproject/v2
# 修改所有 import 为 github.com/yourname/myproject/v2/...
# 提交并打标签
git commit -am "Release v2.0.0"
git tag v2.0.0
git push origin v2.0.0

私有模块

如果你的模块在私有 Git 仓库（比如公司内部仓库），需要额外配置：

# 设置私有仓库模式，Go 会跳过校验和数据库检查
go env -w GOPRIVATE=gitlab.company.com,github.com/company/*

# 或者用 .gitconfig 配置认证
git config --global url."git@github.com:".insteadOf "https://github.com/"
git config --global url."git@gitlab.company.com:".insteadOf "https://gitlab.company.com/"

此外，还需要配置代理：

# 默认的 Go 代理（国内可能会很慢）
go env -w GOPROXY=https://proxy.golang.org,direct

# 国内推荐使用以下代理
go env -w GOPROXY=https://goproxy.cn,direct

# 企业内网可能需要配置私有代理
go env -w GOPROXY=https://internal-proxy.company.com,https://goproxy.cn,direct

如果你的私有仓库需要认证，可以在 ~/.netrc 中配置：

machine gitlab.company.com
login username
password token_or_password

工作区（Workspace）

Go 1.18 引入了 Workspace 模式，方便同时开发多个模块：

# 创建工作区
go work init

# 添加模块到工作区
go work use ./moduleA
go work use ./moduleB
go work use ./moduleC

这会创建一个 go.work 文件：

go 1.22

use (
	./moduleA
	./moduleB
	./moduleC
)

现在你可以在 moduleA 中直接引用 moduleB 的本地代码，不需要 replace 指令。这极大地简化了多模块项目的开发体验。

企业级微服务项目中，通常会使用 workspace 管理一组相关的服务模块：

microservice-platform/
├── go.work
├── api-gateway/
│   ├── go.mod
│   └── main.go
├── user-service/
│   ├── go.mod
│   └── main.go
├── order-service/
│   ├── go.mod
│   └── main.go
└── shared/
    ├── go.mod
    ├── logger/
    ├── errors/
    └── middleware/

# 在根目录执行
cd microservice-platform
go work init api-gateway user-service order-service shared
go build ./...

实战：创建一个可复用的库

让我们创建一个简单的工具库并发布：

// stringutil.go
package stringutil

import "strings"

// Reverse 反转字符串
func Reverse(s string) string {
	runes := []rune(s)
	for i, j := 0, len(runes)-1; i < j; i, j = i+1, j-1 {
		runes[i], runes[j] = runes[j], runes[i]
	}
	return string(runes)
}

// Capitalize 首字母大写
func Capitalize(s string) string {
	if s == "" {
		return s
	}
	return strings.ToUpper(s[:1]) + s[1:]
}

// IsPalindrome 判断字符串是否是回文
func IsPalindrome(s string) bool {
	return s == Reverse(s)
}

// UniqueChars 返回不重复的字符切片
func UniqueChars(s string) []rune {
	seen := make(map[rune]bool)
	result := make([]rune, 0)
	for _, r := range s {
		if !seen[r] {
			seen[r] = true
			result = append(result, r)
		}
	}
	return result
}

初始化模块并添加测试：

go mod init github.com/yourname/stringutil
go mod tidy

// stringutil_test.go
package stringutil

import "testing"

func TestReverse(t *testing.T) {
	tests := []struct {
		input, expected string
	}{
		{"hello", "olleh"},
		{"", ""},
		{"a", "a"},
		{"你好", "好你"},
		{"Hello, 世界", "界世 ,olleH"},
	}

	for _, tt := range tests {
		t.Run(tt.input, func(t *testing.T) {
			result := Reverse(tt.input)
			if result != tt.expected {
				t.Errorf("Reverse(%q) = %q; want %q",
					tt.input, result, tt.expected)
			}
		})
	}
}

func TestIsPalindrome(t *testing.T) {
	tests := []struct {
		input    string
		expected bool
	}{
		{"aba", true},
		{"abc", false},
		{"", true},
		{"a", true},
	}

	for _, tt := range tests {
		t.Run(tt.input, func(t *testing.T) {
			result := IsPalindrome(tt.input)
			if result != tt.expected {
				t.Errorf("IsPalindrome(%q) = %v; want %v",
					tt.input, result, tt.expected)
			}
		})
	}
}

func BenchmarkReverse(b *testing.B) {
	for i := 0; i < b.N; i++ {
		Reverse("Hello, World! This is a benchmark test.")
	}
}

发布到 GitHub：

git init
git add .
git commit -m "Initial commit: string utility library"
git tag v1.0.0
git remote add origin git@github.com:yourname/stringutil.git
git push origin main --tags

其他人就可以在你的项目中使用：

go get github.com/yourname/stringutil@v1.0.0

package main

import (
	"fmt"
	"github.com/yourname/stringutil"
)

func main() {
	fmt.Println(stringutil.Reverse("Hello, Go Modules!"))
	fmt.Println(stringutil.Capitalize("hello"))
}

企业级案例：微服务项目依赖管理

在真实的微服务项目中，依赖管理远比个人项目复杂。以下是一个企业级的 go.mod 管理示例：

module gitlab.company.com/backend/user-service

go 1.22

require (
	github.com/gin-gonic/gin v1.9.1
	github.com/go-sql-driver/mysql v1.7.1
	github.com/redis/go-redis/v9 v9.3.0
	github.com/jinzhu/configor v1.2.2
	github.com/golang-jwt/jwt/v5 v5.2.0
	github.com/sirupsen/logrus v1.9.3
	github.com/prometheus/client_golang v1.17.0
	github.com/opentracing/opentracing-go v1.2.0
	gitlab.company.com/common/logger v1.2.0
	gitlab.company.com/common/errors v0.5.0
)

require (
	github.com/bytedance/sonic v1.9.1 // indirect
	// ... 其他间接依赖
)

replace (
	gitlab.company.com/common/logger => ../common/logger
	gitlab.company.com/common/errors => ../common/errors
)

这种结构下，开发环境利用 replace 进行本地开发，CI/CD 阶段去掉 replace 从私有仓库拉取。配合 Workspace，开发体验非常流畅。

最佳实践

1. 始终使用精确版本

不要使用 @latest 标签作为生产依赖，应该指定确切版本号：

// ✅ 推荐
require github.com/gin-gonic/gin v1.9.1

// ❌ 不推荐（非确定性构建）
require github.com/gin-gonic/gin latest

2. 定期运行 go mod tidy

这是保持依赖文件整洁的最有效方式。建议在以下时机执行：

  • 添加新的 import
  • 删除不再使用的代码
  • 修改 go.mod 后
  • 提交代码前

3. 提交 go.sum 到版本控制

go.sum 是构建可重复性的保障，必须提交到 git：

# .gitignore 中不要有 go.sum
git add go.mod go.sum

4. 使用 Vendor 模式保证CI稳定性

对于关键项目，建议使用 vendor 模式：

go mod vendor
git add vendor/

这样在 CI 构建时可以设置 GOFLAGS="-mod=vendor"，构建速度快且稳定。

5. 利用 Go Proxy 加速下载

# 国内开发者推荐
go env -w GOPROXY=https://goproxy.cn,direct

# 团队协作时统一配置（可通过 Makefile）
make setup
# make setup 内容:
# go env -w GOPROXY=https://goproxy.cn,direct
# go env -w GOPRIVATE=gitlab.company.com

6. 验证依赖安全性

# Go 1.21+ 内置的漏洞扫描
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

7. 许可证合规检查

go install github.com/google/go-licenses@latest
go-licenses csv ./... > licenses.csv

常见问题（FAQ）

Q1: 为什么 go build 时提示 “missing go.sum entry”？

A: 通常是因为 go.mod 中声明了依赖，但 go.sum 中缺少对应的校验和。运行 go mod tidy 可以自动修复这个问题。

Q2: 我可以修改 vendor/ 目录下的依赖代码吗？

A: 可以但不推荐。修改 vendor 代码只在当前项目生效，更新后会丢失。如果需要修改，建议 fork 后到远程仓库并调整 go.mod 的 replace 指令。

Q3: 如何查看某个依赖被哪些包使用？

A: 使用 go mod why 命令：

go mod why -m github.com/some/package

Q4: GOPATH 和 Go Modules 可以共存吗？

A: Go 1.16 以后只要项目目录中有 go.mod 文件，就会自动启用 Modules 模式。没有 go.mod 的项目仍受 GOPATH 影响，但新项目都应该使用 Modules。

Q5: 如何删除不再使用的依赖？

A: go mod tidy 会自动清理。手动删除 go.mod 中的 require 行也可以，但之后必须运行 go mod tidy 来同步 go.sum。

Q6: 为什么我的模块名里包含 /v2，但 import 时也需要它？

A: 因为 Go Modules 将不同主版本视为不同的模块。v2 模块的路径必须包含 /v2，这是语义化版本规范的要求。

Q7: 如何处理循环依赖？

A: Go 不允许包级别的循环依赖。解决方法是：

  • 将公共接口提取到独立的 “interface 包”
  • 使用 dependency injection（依赖注入）
  • 重构代码结构

Q8: 私有仓库的 go get 总是超时怎么办？

A: 请检查：

  1. GOPRIVATE 是否正确设置了你的私有域名
  2. GOPROXY 是否配置正确
  3. SSH 密钥或 HTTPS 凭据是否可以正常认证
  4. 防火墙规则是否允许访问私有仓库

常见陷阱

1. 忘记运行 go mod tidy

这会导致 go.mod 和实际依赖不一致，CI/CD 中构建失败。建议在 git hook 中自动运行：

# .git/hooks/pre-commit
#!/bin/bash
go mod tidy
if [ "$(git diff --name-only | grep -E 'go\\.mod|go\\.sum')" ]; then
    echo "go.mod 或 go.sum 已被更新，请重新提交"
    exit 1
fi

2. 不提交 go.sum

别人拉取你的代码后，构建可能失败或被校验和不匹配的安全机制拒绝。go.sum 是版本控制的一部分。

3. 滥用 replace

replace 应该只是临时方案，不要让它成为常态。发布前应该通过 workspace 或合理的版本规划来处理。

4. 主版本号处理错误

v2+ 必须加主版本后缀，否则会导致版本冲突和无法正确解析。

延伸阅读

参考资料：

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「golang」更多文章

  1. 熔断、降级与限流：Go 微服务韧性设计完全指南
  2. 事件溯源与 CQRS 在 Go 中的实践：复杂业务系统的架构升级
  3. TinyGo 嵌入式开发与物联网实战：微控制器编程完全指南