不靠谱的糖饼1. 为什么 Redis 要设置访问密码
Redis 默认配置是不需要密码的，装完就能直接连，端口 6379 一开，谁都能访问。这在本地开发环境里确实很爽，省事。但只要你把 Redis 部署到服务器上，哪怕只是临时用一下，问题就来了：如果你的服务器 IP 是公网的，或者处在局域网内其他机器也能触达的网络环境，Redis 就会完全暴露在网络上。
我说的暴露不是危言耸听。Redis 本身没有做太多访问控制，默认情况下任何一个能连接到 6379 端口的人，都可以执行 FLUSHALL 把数据清空、可以修改配置、甚至可以通过写 crontab 等方式进一步利用服务器。早年有过不少因为 Redis 未授权访问导致服务器被入侵的案例，攻击者利用 Redis 的 CONFIG SET dir 和 CONFIG SET dbfilename 把恶意内容写入磁盘，拿到服务器权限。所以给 Redis 加密码，不是可选项，而是底线操作。
设置访问密码本质上就是给 Redis 加一层最基础的认证机制。客户端连接时需要提供正确的密码，验证通过后才能执行命令。这样至少挡住了一大批扫描器、脚本小子和误连情况。虽然密码认证不是万能的，比如密码过于简单会被暴力破解，或者内网流量被截获会有泄露风险，但你总得先把门锁装上，再谈要不要装摄像头。
另外一个容易被忽略的原因是：Redis 在不少公司里是多个应用共用的基础组件。可能 A 项目组的服务在跑，B 项目组的任务是做数据分析，也在用同一套 Redis。没有密码的话，任何一个开发者在本地随便连上去执行 KEYS * 或者 FLUSHDB，都可能对别人造成影响。别问我怎么知道的，我见过不止一次。
所以这篇文章就直接讲实操：在 Linux 服务器、Windows 环境、Docker 容器里分别怎么给 Redis 设置访问密码，以及设置完之后怎么验证、怎么排查、有哪些坑。全程按照我自己实际配置环境的经历来写，不是照着官方文档念经。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 设置密码前需要了解的几个概念
2.1 requirepass 和 redis.conf 的关系
Redis 的密码认证配置项叫 requirepass。这个配置项写在 redis.conf 配置文件里，或者用 config set requirepass 命令动态设置。两者的区别在于：
- 写在 redis.conf 里：重启 Redis 后依然生效，适合长期固定的密码策略。
- 用 config set 动态设置：立刻生效，但重启后失效，适合临时调试或者需要热更新的场景。
实际环境中，我一般建议先在配置文件里设置好密码，再启动 Redis。因为这样能确保 Redis 一启动就处于受保护状态，中间不会出现“裸奔”窗口期。有些人习惯先启动 Redis，再用命令行设置，如果你在隔离的本地环境倒还好，如果在公网服务器上，哪怕只裸奔了几分钟，扫描器都可能已经连上来了。
2.2 密码存储的机制
有些刚接触 Redis 的朋友以为 Redis 会把密码明文存在配置文件里，然后每次连接时发送密码比对。实际上 Redis 的 requirepass 配置项在配置文件里确实是明文显示的，但在运行时 Redis 内部会对密码做处理。具体细节这里不多展开，你只要知道：redis.conf 文件里就是明文，所以要保护好这个文件的权限，不要让无关人员可读。另外，如果用了 Redis 6.0 以上版本的 ACL 功能，可以将用户与权限绑定得更细，但普通场景下 requirepass 就够用了。
2.3 连接时密码的传递方式
客户端连接 Redis 时，需要通过 AUTH 命令提交密码。如果你用 redis-cli，可以这样：
bash
redis-cli -h 127.0.0.1 -p 6379 -a yourpassword
在命令行里直接带 -a 参数确实方便，但要注意：这会出现在 shell 的历史记录里，也会被进程列表看到。所以生产环境我更推荐先登录进去再执行 AUTH：
bash
redis-cli
127.0.0.1:6379> AUTH yourpassword
OK
如果用可视化客户端，一般会在连接配置里有一个密码输入框，比如 Redis Desktop Manager 或者 Another Redis Desktop Manager，填上就行。
这里就引出了一个问题：密码设成什么样才算安全？下面单独说一下。
2.4 密码强度与使用策略
Redis 的密码没有强制复杂度要求，你设个 123456 它也能接受。但这不意味着你应该这么干。Redis 的认证是明文传输的，也就是说密码在网络里是以明文形式被发送的（除非你用 TLS 加密连接），所以密码本身不能太弱。
我个人的经验是：
- 密码长度至少 16 位以上。
- 混合大小写字母、数字、特殊字符。
- 不要用生日、公司名、业务名等容易猜到的组合。
- 不要所有环境共用一套密码，开发、测试、生产分开。
密码强弱的权重我甚至觉得比加不加 TLS 更重要，因为在很多内网环境里，攻击者获取流量抓包的成本比直接爆破要低。你密码够长够随机，即使流量被截获，对方拿到的也是一个难以利用的凭证。
3. 在 Linux 服务器上设置 Redis 密码
3.1 找到你的 redis.conf
最常见的 Redis 安装方式有几种：源码编译安装、apt/yum 安装、Docker 容器。不管哪种，配置文件一般叫 redis.conf，位置会在这些路径里：
- /etc/redis/redis.conf（apt/yum 安装常见）
- /usr/local/redis/redis.conf（源码编译安装时看你 --prefix 指定哪里）
- /opt/redis/redis.conf
- 当前工作目录下的 redis.conf（如果手动启动的）
如果你不确定在哪里，可以用 find 命令找：
bash
find / -name "redis.conf" 2>/dev/null
或者你直接看启动方式。如果用 systemctl 启动 Redis，配置文件路径通常写在 /lib/systemd/system/redis.service 或者 /etc/systemd/system/redis.service 里，找到 ExecStart 那行：
bash
ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf
ExecStart 后面的路径就是配置文件路径。
3.2 修改 requirepass 配置项
打开 redis.conf，找到这一行：
requirepass foobared
默认情况下这一行是被注释掉的。把注释符号去掉，并且把 foobared 替换成你自己的密码，就像这样：
requirepass YourStrongPassword2024!
保存退出。
这里有个细节：Redis 配置文件的语法很宽松，requirepass 和密码之间有一个空格即可。如果你的密码里包含空格、引号等特殊字符，建议用引号括起来，比如：
requirepass "Your Strong Password 2024!"
不过我不推荐密码带空格，因为它会在你敲命令行时带来各种转义问题。密码里的特殊字符最好控制在 !@#$%^&*()_+-= 这类常见范围内，避免出现引号、美元符号、反斜杠等容易踩坑的字符。
3.3 重启 Redis 服务
修改完配置后，需要重启 Redis 才能生效。分两种启动方式来看。
如果用的是 systemd：
bash
sudo systemctl restart redis
sudo systemctl status redis
如果直接是 redis-server 进程，你需要先杀掉再重启：
bash
ps -ef | grep redis
kill
redis-server /path/to/redis.conf
如果你不想重启 Redis 服务，也可以动态设置：
bash
redis-cli
127.0.0.1:6379> CONFIG SET requirepass YourStrongPassword2024!
OK
注意：动态设置不需要重启，从下一条 AUTH 开始就必须用新密码了。但如果后续 Redis 重启，这个设置就会丢失，因为配置没有写回文件。如果想让动态设置永久生效，还需要执行：
bash
127.0.0.1:6379> CONFIG REWRITE
OK
这个命令会把当前运行配置写回 redis.conf。我一般在临时调试时会用这种方式，但正式环境还是直接改文件更稳妥。
3.4 验证密码是否生效
设置完之后，最简单直接的验证方式：
bash
redis-cli
127.0.0.1:6379> PING
(error) NOAUTH Authentication required.
127.0.0.1:6379> AUTH YourStrongPassword2024!
OK
127.0.0.1:6379> PING
PONG
看到 NOAUTH 就说明密码已经生效了。需要注意：Redis 2.6 之前的版本在有密码时执行 PING 会直接返回 NOAUTH，之后的版本会先要求认证再执行命令。现在绝大多数环境都是新版本，所以上面的现象是常见的。
再用带密码的方式连接试试：
bash
redis-cli -h 127.0.0.1 -p 6379 -a YourStrongPassword2024! PING
PONG
这样验证就完成了。
3.5 调整配置文件权限
谈到 redis.conf 的权限，我得特别提醒一句：Redis 的密码是明文写在配置文件里的，所以这个文件的权限要严格控制。修改完之后：
bash
sudo chmod 600 /etc/redis/redis.conf
sudo chown redis:redis /etc/redis/redis.conf
code复制
如果你用源码编译安装并且用非 redis 用户启动，需要根据实际情况调整属主和属组。这个步骤容易被忽略，因为你只关注密码功能本身，但权限问题万一出事儿就是大事。
在 Windows 上没有单独的 chmod，但可以通过文件属性对话框把其他用户的读取权限去掉，只保留管理员和当前用户的访问权。具体操作不复杂，右键属性 -> 安全 -> 编辑权限。
## 4. 在 Windows 上设置 Redis 密码
### 4.1 Windows 版 Redis 的配置差异
Windows 上装 Redis 一般是用微软维护的移植版，或者是 tporadowski 的 Redis for Windows（常见 5.0.14.1 版本），再或者通过 Docker Desktop 跑 Linux 容器。不管哪种，配置文件基本思路和 Linux 一致，只是文件路径和启动方式有差别。
如果是从 zip 包解压的 Redis，目录下通常有 redis.windows.conf 或 redis.conf。以 tporadowski 的 5.0.14.1 为例，解压后的目录长这样：
- redis-server.exe
- redis-cli.exe
- redis.windows.conf
- redis-benchmark.exe
启动时用：
bash
redis-server.exe redis.windows.conf
所以要修改密码，就是编辑 redis.windows.conf，找到 requirepass 那一行，去掉注释并填上密码。
### 4.2 用 redis-cli 修改密码
如果 Redis 已经启动了，也可以用 redis-cli 动态设置：
bash
redis-cli.exe -h 127.0.0.1 -p 6379
127.0.0.1:6379> CONFIG SET requirepass YourStrongPassword2024!
OK
然后验证：
bash
redis-cli.exe -a YourStrongPassword2024!
127.0.0.1:6379> PING
PONG
在 Windows 上同样建议直接改配置文件，因为动态设置重启后会丢，除非你执行 CONFIG REWRITE。但 Windows 移植版的 CONFIG REWRITE 偶尔会有兼容问题，所以最稳妥的方式还是改配置文件再重启。
### 4.3 Windows 上常见的坑
Windows 版 Redis 有个问题：配置文件里的路径分隔符、行尾符可能会影响加载。如果你在 Linux 上编辑过 redis.conf 再传到 Windows 上，可能会出现无法加载配置的情况。一般解决办法是把文件另存为 CRLF 行尾格式，或者在 Windows 上重新编辑。
还有一个坑是 Windows 防火墙。Redis 默认监听 6379，如果你要让其他机器连接，需要放行入站规则。但如果只是本机使用，那就不需要放行。设置密码后，即使防火墙放行了，没有密码的客户端也无法连接。我见过有人不知道这一点，以为防火墙放行后密码就没用了，其实不是这样，密码认证和防火墙是两层不同的防护。
### 4.4 可视化客户端连接测试
Windows 上很多人用可视化工具，比如 Redis Desktop Manager、Another Redis Desktop Manager、Redis Insight 等。连接时只需要填写 Host、Port、Password 三个字段就行。如果你的 Redis 设置了密码，连接测试时填错密码会直接报错，提示认证失败。
这里提醒一下：Another Redis Desktop Manager 对 Redis 6.0+ 的 ACL 支持比较好，可以填用户名和密码。Redis 5.0 及以下版本只需要密码。所以用旧版 Redis 时，用户名留空即可。
## 5. 在 Docker 部署的 Redis 上设置密码
### 5.1 通过命令行参数直接设置
现在很多人的 Redis 是用 Docker 跑的，因为部署简单、环境隔离，一个命令就能起一个实例。Docker 版 Redis 设置密码有几种常见方式。
最简单的方式是在 docker run 时通过命令行参数指定 redis-server 的启动参数。镜像的默认入口就是 redis-server，所以可以这样：
bash
docker run -d --name redis-auth \
-p 6379:6379 \
redis:7.0 \
redis-server --requirepass YourStrongPassword2024!
看到没，在镜像名后面那串 redis-server --requirepass YourStrongPassword2024! 就是覆盖默认 CMD，以带密码的方式启动 Redis。这种方式适合快速验证，但密码明晃晃地写在进程启动参数里，会被 docker inspect 看到，风险较高，所以生产环境不推荐这样。
### 5.2 通过配置文件设置
更规范的方式是挂载配置文件。先在宿主机上准备一个 redis.conf，比如 /data/redis/conf/redis.conf，内容里写上：
requirepass YourStrongPassword2024!
然后启动容器：
bash
docker run -d --name redis-auth \
-p 6379:6379 \
-v /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf \
redis:7.0 \
redis-server /usr/local/etc/redis/redis.conf
注意：如果你挂载的是一个只包含 requirepass 的迷你配置文件，那么 Redis 只会加载这个文件里的配置，而默认配置里的其他参数不会加载。这可能会导致一些默认行为变化，比如持久化配置、最大内存策略等。如果你不确定，建议把原始 redis.conf 从镜像里 cp 出来，在它基础上修改，再挂载回去。
具体操作是：
bash
docker run --rm -v /data/redis/conf:/data redis:7.0 cp /usr/local/etc/redis/redis.conf /data/redis.conf
这样把镜像里的默认配置导出到宿主机，然后再编辑，避免遗漏默认配置项。
### 5.3 Docker 环境下连接方式的差异
在 Docker 环境里，如果你只映射了宿主机的 6379 端口到容器内的 6379，那么宿主机访问 Redis 时用：
bash
redis-cli -h 127.0.0.1 -p 6379 -a YourStrongPassword2024!
但如果其他容器要访问 Redis，需要确保它们在同一个 Docker 网络下，或者在启动 Redis 容器时指定了 --network 为某个自定义网络，然后通过容器名访问，比如：
bash
docker network create redis-net
docker run -d --name redis-auth --network redis-net -p 6379:6379 ...
redis-cli -h redis-auth -p 6379 -a YourStrongPassword2024!
code复制
如果你用 Docker Compose，写法稍微有一点不同：
yaml
services:
redis:
image: redis:7.0
container_name: redis-auth
ports:
- "6379:6379"
command: redis-server --requirepass YourStrongPassword2024!
或者挂载自定义配置文件：
yaml
services:
redis:
image: redis:7.0
container_name: redis-auth
ports:
- "6379:6379"
volumes:
- /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf
command: redis-server /usr/local/etc/redis/redis.conf
code复制
这里需要注意，compose 文件里的密码如果直接明文写，一定要确保 compose 文件本身权限可靠，不要让所有开发人员都能看到。更稳妥的方式是使用环境变量结合 entrypoint 脚本，但那样复杂度上去了，小团队没必要为了这个过度设计。我的建议是先把密码写进配置文件，配置文件权限设为 600，compose 文件保持简单。
### 5.4 重启与验证
Docker 容器改完配置后，重启容器不会自动重新加载配置，因为配置是启动时加载的。你需要先停掉再删掉容器，然后重新创建容器。如果只是 docker restart，那还是用旧配置启动的，密码不会变化。所以建议：
bash
docker stop redis-auth
docker rm redis-auth
docker run -d ...（重新跑一遍）
验证方法和前面一样：
bash
redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> AUTH YourStrongPassword2024!
OK
code复制
这一步必须做。有很多人改完配置以为生效了，结果容器重启时忘记重新创建，导致新配置根本没加载，密码没变。我踩过这个坑，所以在这里特别强调。
## 6. 设置密码后的常见问题与排查方法
### 6.1 连接时报 NOAUTH Authentication required
这是最典型的现象，你在没有认证的情况下执行命令就会看到。解决办法就是先执行 AUTH 再操作，或者在连接时带上 -a 参数。
但这里有个常见误解：有的客户端工具会先发一条 PING 来检测连接是否可用，如果服务器要求认证，客户端可能会把这个 NOAUTH 响应当成连接失败。所以如果你用可视化工具连接，报错信息里说“Authentication required”，不要慌，这只是说明认证没通过，不是 Redis 挂了。检查一下密码对不对。
### 6.2 认证时密码包含特殊字符导致失败
如果密码里包含 !、$、& 等字符，在 bash 里执行：
bash
redis-cli -a Your!Strong$Password
有很大概率被 shell 解释掉。! 在 bash 中有历史展开的副作用，$ 后面跟的内容会被当成变量。所以建议要么用单引号把密码包起来：
bash
redis-cli -a 'Your!Strong$Password'
code复制
要么进入交互模式后用 AUTH 命令，那样不存在 shell 转义的问题。如果你把密码直接写在 redis.conf 里，Redis 解析时对特殊字符的处理也有讲究，最简单的办法是不要用这种特殊字符。密码安全性和可维护性要平衡。
### 6.3 密码设置后原有客户端全部失效
这个很直观。你在运行中的 Redis 上执行 CONFIG SET requirepass 后，所有已建立的连接不会立刻断开，但当它们尝试执行下一条命令时，会因为未认证而报错。有些客户端库内部有连接池，连接池里的连接如果还处于未认证状态，后续请求就会失败。所以生产环境动态修改密码时，要提前通知所有使用方，并且准备好重启应用或者重新建立连接池。
如果想优雅一点，可以先用 ACL 创建一个临时用户，然后逐步迁移到新用户，最后再把老用户删掉。但大多数团队不会为 Redis 搞这么复杂，通常就是改完密码后让应用部署一次。
### 6.4 Redis 日志里出现大量的 AUTH failed
如果日志里频繁出现 AUTH failed，通常说明有人在尝试用错误密码连接你的 Redis，可能是扫描器在试探。这时候除了确认自己的客户端是否配置正确外，还要考虑是否应该限制来源 IP。
Redis 本身没有内置 IP 白名单功能（除非用防火墙或安全组）。我建议的做法是：
- 如果 Redis 只给少数几台服务器用，那就用防火墙限制来源 IP，比如 iptables 或云安全组只放行这些服务器的 IP。
- 如果 Redis 绑定了 0.0.0.0，可以改成只监听内网 IP，比如 bind 192.168.1.100，这样公网根本无法直接访问。
- 同时启用密码，双保险。
### 6.5 忘记密码怎么办
万一你设置了密码但忘了，最直接的办法是登录到 Redis 所在的机器，找到 redis.conf，看里面的 requirepass 明文。如果你已经通过 CONFIG SET 设置过了但没写回文件，也可以尝试用 redis-cli 连上去（如果已经认证过，还在同一个会话里），执行 CONFIG GET requirepass 查看当前密码。如果所有连接都被认证挡住，那就只能停掉 Redis，临时去掉密码再启动、查看配置，或者直接把 requirepass 设成空再重启。
但这个操作要小心。如果你在公网服务器，停掉 Redis 改为无密码再启动，哪怕只有几秒钟，也是不安全窗口。建议先修改 redis.conf 里的 requirepass 为空白或新密码，然后重启 Redis，这样重启过程中始终不裸奔。具体做法是：先改配置，再重启。
### 6.6 如何验证密码的安全性
设置完密码后，除了验证能不能连上，我还会做一次简单的弱口令扫描自测，比如用 redis-cli -a 123456 试着连一下，看会不会成功。如果真能成功，说明密码太弱，赶紧换掉。另外可以检查一下 redis.conf 的权限，确保只有 redis 用户和管理员能读。
有些团队还会把密码写进 CI/CD 的配置仓库里，如果不小心提交到了公共仓库，那基本等于泄露了。建议在项目里用 .gitignore 忽略配置文件，或者用密钥管理工具集中管理。这是安全领域的常识，但 Redis 这种基础组件往往不是被重点审查的对象，所以更容易出问题的其实是流程。
### 6.7 常见问题排查速查表
| 问题现象 | 可能原因 | 排查方式 | 解决方法 |
| --- | --- | --- | --- |
| 连接报 NOAUTH | 需要认证 | 执行 AUTH 后测试 | 连接时输入密码 |
| AUTH 失败 | 密码错误或特殊字符转义 | 检查密码是否正确、shell 是否转义 | 用单引号或交互模式 |
| 重启后密码失效 | 只用了 CONFIG SET 没写回文件 | 查看 redis.conf 是否有 requirepass | 修改 redis.conf 并重启 |
| Docker 容器配置不生效 | 容器启动时没加载新配置 | docker inspect 查看启动命令 | 删容器重新创建，确认 command 正确 |
| 客户端工具连接失败 | 密码包含特殊字符或版本不支持 ACL | 检查工具版本和密码格式 | 密码保持简单或升级客户端 |
## 7. Redis ACL 方式设置密码
如果你用的是 Redis 6.0 及以上版本，我强烈建议了解一下 ACL 机制。传统 requirepass 相当于只有一个全局密码，所有客户端共用。ACL 则可以为不同用户设置不同密码，并且限制用户可以执行哪些命令、访问哪些 key。这在多人共用一个 Redis 的场景下非常有用。
一个简单的 ACL 示例：
bash
redis-cli -a YourStrongPassword2024!
127.0.0.1:6379> ACL SETUSER appuser on > AppUserPassword2024! ~app:* +@all
OK
这条命令创建了一个名为 appuser 的用户，密码为 AppUserPassword2024!，只能访问 app: 前缀的 key，可以执行所有命令。如果只想让它拥有基本读写权限：
bash
ACL SETUSER appuser on > AppUserPassword2024! ~app:* +get +set +del +exists +expire +ttl
code复制
这样权限范围更窄，也更安全。
ACL 的配置也可以写进 redis.conf：
user appuser on >AppUserPassword2024! ~app:* +@all
保存后重启或 CONFIG REWRITE 生效。
ACL 比 requirepass 复杂，但它能解决很多权限边界问题。如果你只是给 Redis 设个密码防止未授权访问，requirepass 已经够了。如果团队里有人需要只读权限、有人需要管理权限，那就值得上 ACL。
## 8. 密码设置好后的一些经验建议
### 8.1 定期更换密码
Redis 密码和服务器密码一样，不能设一次就永远不变。尤其是人员变动时，比如有开发人员离职，而他知道 Redis 密码，那就应该马上更换。虽然这有点麻烦，但总比泄露后出事再补救强。我见过一些团队两年不换 Redis 密码，最后发现有离职员工的脚本还在定时连生产 Redis，细思极恐。
### 8.2 密码分发与管理
密码分发不要通过即时聊天工具明文发。最稳妥的方式是通过密钥管理系统，比如 Vault、KMS 之类的，把 Redis 密码作为密钥存储，应用启动时动态读取。如果团队规模小，没有这些系统，那也至少要把密码放到一个单独的配置仓库里，严格限制访问权限。
### 8.3 开启持久化后的注意事项
如果 Redis 开了 RDB 或 AOF 持久化，密码配置也会被记录在持久化文件里吗？答案是：不会。密码只保存在 redis.conf 或运行时配置中，不会写进 RDB 文件。所以不用担心备份出来的 RDB 文件泄露密码。但备份文件本身是敏感数据，还是应该限制访问。
### 8.4 监控未授权访问尝试
在 Redis 日志里，AUTH failed 是一个很明显的异常信号。如果你有日志采集系统，可以针对这个关键词设置告警。短期内少量失败可能是客户端配置错了，但如果某个 IP 不断尝试，大概率是有人在暴力破解。这时候就要考虑加上防火墙限制。
### 8.5 一个完整的设置流程建议
最后我把整个流程串起来，作为一套可以直接执行的 checklist：
1. 找到 redis.conf 文件位置。
2. 备份 redis.conf（cp 一份带日期后缀）。
3. 在 redis.conf 里设置 requirepass 为强密码。
4. 修改 redis.conf 文件权限为 600，属主改为 redis 运行用户。
5. 重启 Redis，确认启动无报错。
6. 用无密码方式连接一次，确认返回 NOAUTH。
7. 用 AUTH 认证后执行 PING，确认返回 PONG。
8. 用可视化客户端连接，确认能正常操作。
9. 通知所有业务方更新连接配置。
10. 检查监控告警，确认日志中没有异常认证失败。
这十条做完，Redis 密码基本就设置稳妥了。
我个人在实际配置中体会最深的一点是：Redis 密码设置本身不复杂，复杂的是流程中的细节——比如配置文件权限、特殊字符的转义、Docker 容器的重启方式。任何一个环节没注意，都可能出现“明明设置了密码，结果没生效”或者“密码太弱等于没设”的情况。所以建议你参考上面的完整流程，一步一步来，别嫌麻烦。安全这种事，总是先苦后甜的。