前阵子帮朋友在腾讯云上搭了一套业务系统需求很明确一台 Ubuntu 24.04 的云服务器数据库选 PostgreSQL并且要求以后迁移、升级、回滚都要省心。我二话没说就定了 Docker 方案。说实话放到现在如果还有人纠结“要不要用容器跑数据库”我的建议很直接——中小型项目、创业阶段的业务、自动化和 DevOps 流程比较完善的情况Docker 部署 PostgreSQL 的收益远大于风险。这篇文章就完整记录我在腾讯云上从零开始的操作过程包括环境初始化、Docker 安装、PostgreSQL 容器化部署、备份策略和踩坑记录照着做基本可以复现一套干净、可用、相对规范的数据库服务。文章适合谁看大概两种人一是想在云服务器上快速跑起 PostgreSQL 但不想被源码编译、依赖库、系统包管理折腾的开发者二是公司内部要用 PostgreSQL想建一套能迁移、能备份、可重复部署的数据库环境的运维同学。文章里我会把每一步为什么这么做的逻辑讲清楚而不是单纯丢一串命令。1. 部署前想清楚的事为什么偏要用 Docker 跑 PostgreSQL1.1 直接装 PostgreSQL 和用 Docker 跑有什么差别很多人第一次接触 PostgreSQL第一反应是“apt install postgresql 不就行了吗”。确实Ubuntu 的软件源里就有现成版本装上之后 systemctl 一启动就算完事。但原生安装有几个硬伤第一版本管理不灵活。Ubuntu 24.04代号 noble自带的是 PostgreSQL 16但你的业务可能跑在 14 或者 15 上也可能你想提前体验 17 的新特性。想在同一台机器上共存两个大版本原生安装会比较痛苦用 Docker 反而简单不同容器用不同镜像 tag 即可。第二依赖环境不可控。PostgreSQL 有很多扩展插件比如 PostGIS、pgvector又比如 Citus 这类分布式方案它们的系统依赖和版本匹配关系经常让人头疼。容器镜像把这些依赖都封装好了换台机器直接 pull 镜像就能跑这是原生安装很难做到的。第三备份和迁移的“颗粒度”不同。原生安装的数据文件散落在 /var/lib/postgresql、/etc/postgresql、/var/log/postgresql 等目录迁移时要考虑一堆路径。容器方案把数据目录集中放在一个指定的 volume 里备份时只需要处理这个目录逻辑清晰很多。我做了一张对比表方便你根据自己的场景判断对比项原生 apt 安装Docker 容器部署安装速度取决于源速度一般几分钟拉取镜像慢的话要等但可以配置加速源多版本共存困难需手动配置不同端口和目录轻松一个端口对应一个容器环境一致性依赖宿主机系统状态镜像即环境一致性强备份迁移涉及多个系统目录主要处理数据卷即可升级回滚升级容易出幺蛾子回滚更麻烦换镜像 tag 就能升级旧镜像还能留着回滚运维门槛熟悉 systemd 和 PostgreSQL 配置即可需要额外理解 Docker 的存储、网络、日志机制我个人的看法是如果是个人学习、中小业务或 CI/CD 环境优先选 Docker如果是有专门的 DBA 团队、对性能压榨到极致、或者对操作系统级监控有严格合规要求的核心生产库再考虑物理机或云厂商的托管数据库。1.2 服务器选型与 Ubuntu 24.04 镜像选择腾讯云上买服务器的时候地域、机型、带宽这些看业务需求我只提醒几个和本文相关的点操作系统选 Ubuntu 24.04 LTS。腾讯云控制台里可以选择“公共镜像”通常已经包含了最新安全补丁。LTS 版本支持周期长5 年内都有安全更新跑数据库比较安心。系统盘建议留 50G 以上。Ubuntu 24.04 装完系统加上 Docker 镜像、容器日志再去掉一些缓存20G 的小盘子会很紧张。我当时踩过一次坑系统盘只给了 40G跑了一段时间后 Docker overlay 分区满了数据库写入直接报磁盘不足。数据盘单独买一块建议挂载到 /data 之类的目录数据库数据放数据盘这样万一系统盘出问题需要重装系统数据盘还能保留。如果是内网系统、测试环境带宽选 1M~3M 就够如果要给外部客户端提供数据库连接带宽和流量需要额外评估。腾讯云服务器的安全组也是很多人忽略的地方。Ubuntu 24.04 默认防火墙可能是关闭的但云平台层面的安全组是默认拦截所有入站流量的必须显式放行。我建议的安全组入站规则至少包含 SSH22、PostgreSQL5432如果完全不需要公网访问数据库5432 端口可以不对公网开放只允许内网 IP。这个后面第四部分还会再提到。2. 初始化腾讯云服务器装好 Docker 环境2.1 安全组与 SSH 登录准备拿到服务器后第一件事不是急着装东西而是把 SSH 登录环境准备好。腾讯云的 Ubuntu 镜像默认带了一个 ubuntu 用户root 登录默认被禁止。我习惯的做法是在控制台把 SSH 密钥对绑定到服务器这样比密码登录安全很多创建自己的部署账号比如叫 deploy并加入 sudo 组修改 sshd_config把 PasswordAuthentication 设为 no只允许密钥登录本地连接时直接通过堡垒机或跳板机访问不把 SSH 服务直接暴露到公网或者至少限定来源 IP。# 在服务器上用 ubuntu 用户执行 sudo apt update sudo apt install -y curl ca-certificates sudo useradd -m -s /bin/bash deploy sudo usermod -aG sudo deploy # 把本地公钥写入 deploy 用户 sudo mkdir -p /home/deploy/.ssh echo 你的公钥内容 | sudo tee /home/deploy/.ssh/authorized_keys sudo chown -R deploy:deploy /home/deploy/.ssh sudo chmod 700 /home/deploy/.ssh sudo chmod 600 /home/deploy/.ssh/authorized_keys为什么不用 root 直接干活因为数据库容器一旦被攻破容器内进程的权限只和你启动容器时的用户有关如果直接用 root风险敞口会大很多。我一般预留一个权限可控的部署账号数据库数据目录也都指派给这个账号管理权限粒度和审计都更清晰。2.2 安装 Docker Engine官方脚本 国内源配置Ubuntu 24.04 上安装 Docker 有很多种方式官方文档推荐用 apt 仓库安装我实际体验下来在腾讯云上更顺手的是先装依赖再配置软件源然后安装 docker-ce 系列包。# 更新索引并安装依赖 sudo apt update sudo apt install -y apt-transport-https ca-certificates curl software-properties-common gnupg lsb-release # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加 Docker apt 仓库这里用了清华源国内访问比较快 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin如果你不想手动配仓库也可以直接用官方脚本curl -fsSL https://get.docker.com | sh这个脚本会自动识别 Ubuntu 24.04 并配置好仓库。唯一的问题是它默认使用官方源在国内云服务器上拉取可能比较慢甚至超时。建议还是按上面手动源的方式走一遍稳一点。装完之后别忘了启动验证sudo systemctl enable --now docker sudo systemctl status docker sudo docker version为了避免每次敲 docker 命令都要加 sudo我习惯把当前用户加入 docker 用户组sudo usermod -aG docker $USER newgrp docker这里特别说一下很多人搞混了 Docker Engine 和 Docker Desktop。Docker Desktop 是面向个人桌面系统的图形化工具需要 GUI 和虚拟化支持服务器上跑的应该是 Docker Engine只有命令行工具和后台 daemon两者完全不是一回事。网上搜“docker desktop 安装教程”学来的套路在云服务器上基本用不上。2.3 配置 Docker 镜像加速国内服务器拉取 Docker Hub 镜像经常遇到网络问题。腾讯云有提供容器镜像加速服务你可以在控制台的容器镜像服务里找到专属加速地址也可以直接使用腾讯云内网地址https://mirror.ccs.tencentyun.com。配置方式是在/etc/docker/daemon.json中设置{ registry-mirrors: [https://mirror.ccs.tencentyun.com] }然后重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker如果加速源拉取失败可以临时用docker pull直连试试实在不行考虑通过其他可用的镜像源拉取或使用代理环境。这个就看你的网络条件了。拉取镜像的时间和网络质量直接挂钩配置好加速源后后面部署 PostgreSQL 镜像会顺畅很多。3. PostgreSQL 容器化部署实操3.1 规划数据目录与容器命名规范动 docker run 之前我强烈建议先把目录结构规划好不然后面数据备份和管理会非常乱。我常用的目录结构是这样/data/postgres ├── data # PostgreSQL 数据文件主数据目录 ├── backup # 定时备份输出目录 └── logs # 容器日志或备份日志创建目录并把权限交给当前用户sudo mkdir -p /data/postgres/{data,backup,logs} sudo chown -R $USER:$USER /data/postgres容器命名我建议带上项目或环境标识例如postgres-main或postgres-test。如果一台机器上要跑多个 PostgreSQL 实例不同版本、不同环境命名和端口规划一定要提前说好我用过的命名方式是postgres-version-env比如postgres-16-prod。端口方面宿主机 5432 只留一个容器用多实例时依次使用 5433、5434对应关系写进注释防止以后自己都搞不清。3.2 编写 docker-compose.yml 与关键参数说明在实际部署中我不用裸 docker run而是坚持用 docker compose。原因很简单配置可跟踪、可回滚、可重复执行。我把环境变量、卷映射、端口映射都固化在一个 yml 文件里后续换机器只需要把这个文件拷过去执行docker compose up -d就能得到一样的服务。这是我在腾讯云 Ubuntu 24.04 上实际使用的 docker-compose.ymlservices: postgres: image: postgres:17-alpine container_name: postgres-main restart: unless-stopped environment: POSTGRES_USER: appuser POSTGRES_PASSWORD: ChangeMe_StrongPassword POSTGRES_DB: appdb TZ: Asia/Shanghai PGDATA: /var/lib/postgresql/data/pgdata ports: - 5432:5432 volumes: - /data/postgres/data:/var/lib/postgresql/data - /data/postgres/backup:/backup shm_size: 256mb healthcheck: test: [CMD-SHELL, pg_isready -U appuser -d appdb] interval: 10s timeout: 5s retries: 5 logging: driver: json-file options: max-size: 50m max-file: 3逐项说一下我为什么这样写image: postgres:17-alpine我选择了当前稳定的主版本 17alpine 镜像体积小、启动快日常够用。如果业务用到了比较冷门的扩展建议改用postgres:17Debian 版兼容性更好。POSTGRES_USER和POSTGRES_DB容器首次初始化时会创建指定用户和数据库。我建议为业务单独建用户而不要直接用默认的 postgres 超级用户跑业务。PGDATA重点说一下。PostgreSQL 官方镜像默认数据目录是/var/lib/postgresql/data我把它改成子目录/var/lib/postgresql/data/pgdata是为了避免权限和挂载冲突。如果你不设置 PGDATA直接在/var/lib/postgresql/data挂载卷也可以但一旦遇到文件权限问题排查起来会稍微麻烦一点。shm_size: 256mbPostgreSQL 在使用并行查询、大量连接时会用到共享内存官方镜像默认的/dev/shm大小是 64MB偶尔会出现could not resize shared memory segment之类的错误所以我直接提到了 256MB。healthcheck容器健康检查很重要后面用 systemd 守护服务或者做自动恢复时都要依赖健康状态。创建文件后启动cd /data/postgres docker compose up -d首次启动会拉取镜像并初始化数据目录日志里会看到类似database system is ready to accept connections的输出看到这行基本就说明 PostgreSQL 已经跑起来了。3.3 启动验证与基础检查容器起来之后验证工作不能省。我一般会从三个层面去检查容器状态、数据库连通性、数据目录持久化是否生效。# 查看容器状态和健康状态 docker ps # 查看启动日志 docker logs postgres-main # 进入容器执行 SQL docker exec -it postgres-main psql -U appuser -d appdb -c SELECT version(); # 验证数据卷里的文件是否真的落盘 ls -l /data/postgres/data/pgdata连接正常的话SELECT version();会返回类似PostgreSQL 17.2 on x86_64-pc-linux-musl的结果。接着建议顺手验证一下外部连接从宿主机或另一台内网机器psql postgresql://appuser:ChangeMe_StrongPassword127.0.0.1:5432/appdb -c SELECT 1;如果宿主机没有安装 psql 客户端可以直接用容器内的 psql 来测试网络链路docker exec postgres-main psql -h 127.0.0.1 -U appuser -d appdb -c SELECT 1;这里有一个很容易被忽略的点docker exec里执行psql -h 127.0.0.1走的是容器网络栈测试的是 PostgreSQL 容器内部监听是否正常从宿主机用psql -h 127.0.0.1走的是宿主机网络栈再经过 Docker 端口映射转发到容器。两者还不完全一样链路排查时要分开看待。4. 让 PostgreSQL 跑得稳又安全资源限制、备份与守护4.1 设置资源限制与自动重启策略容器默认是不限制 CPU、内存使用的如果同一台服务器上还跑了 Nginx、Redis、业务应用PostgreSQL 可能会抢资源。我建议在 compose 文件里加上部署约束deploy: resources: limits: cpus: 2.0 memory: 2G reservations: cpus: 0.5 memory: 512M注意deploy.resources在 docker compose 直接执行时是生效的即使不通过 Swarm 模式新版 Docker 也支持这些约束。CPU 限制 2 核、内存限制 2G 这个数值是根据业务量和 PostgreSQL 配置来的你需要结合自己的并发连接数、work_mem、shared_buffers 等参数综合调整。restart: unless-stopped是必须写的。它的含义是容器进程异常退出时自动重启但如果你手动执行docker compose stop它不会自动拉起。这样既保证了故障自愈又保留了手动维护的主动性。我曾经遇到过服务器负载过高导致 OOM容器被内核杀掉如果没有这个重启策略数据库可能就悄悄地挂了直到业务方打电话过来才发现。4.2 备份与恢复脚本给数据上个双重保险容器跑得再稳也不能替代备份。PostgreSQL 的备份主流方案是pg_dump逻辑备份和pg_basebackup物理备份我日常用得最多的是pg_dump简单可靠适合中小型数据库。在宿主机上创建备份脚本/data/postgres/backup.sh#!/bin/bash DATE$(date %Y%m%d_%H%M%S) DB_NAMEappdb BACKUP_DIR/data/postgres/backup CONTAINERpostgres-main DB_USERappuser # 使用容器内的 pg_dump 导出 SQL 格式备份 docker exec $CONTAINER pg_dump -U $DB_USER -d $DB_NAME --formatplain --no-owner $BACKUP_DIR/${DB_NAME}_${DATE}.sql # 压缩备份文件减少磁盘占用 gzip $BACKUP_DIR/${DB_NAME}_${DATE}.sql # 清理 7 天前的备份只保留一周内的 find $BACKUP_DIR -name *.sql.gz -mtime 7 -delete给脚本执行权限并加入 crontabchmod x /data/postgres/backup.sh crontab -e# 每天凌晨 2 点执行备份 0 2 * * * /data/postgres/backup.sh /data/postgres/logs/backup.log 21恢复的时候很简单一条命令就能搞定# 先创建目标数据库如果不存在 docker exec postgres-main createdb -U appuser appdb_restore # 导入备份 gunzip -c /data/postgres/backup/appdb_20250101_020000.sql.gz | docker exec -i postgres-main psql -U appuser -d appdb_restore注意备份脚本里的--no-owner参数。如果不加还原时会尝试设置对象属主如果你备份时候是用 superuser 执行的还原到另一个环境可能报权限错误加上--no-owner可以规避这类问题对象会归还原时执行 psql 的用户。同理如果跨环境迁移建议也加上--no-acl避免权限定义冲突。我经历过几次数据库误删表的事故恢复时全靠这几个备份文件救命。所以强烈建议备份脚本写完之后先手动跑一遍确认生成的 sql.gz 文件能成功导入到另一个库再交给 crontab 自动化。4.3 让容器跟着系统启动systemd 守护 Docker Compose云服务器重启后Docker 服务会自动启动但是 docker compose 里的容器默认不一定会自动拉起。虽然 compose 文件里写了restart: unless-stoppedDocker daemon 启动时理论上会把符合条件的容器拉起来但为了更稳妥我还会加一层 systemd 服务来管理整个 compose 项目。创建文件/etc/systemd/system/postgres-main.service[Unit] DescriptionPostgreSQL Docker Compose Service Requiresdocker.service Afterdocker.service network-online.target [Service] Typeoneshot RemainAfterExityes WorkingDirectory/data/postgres ExecStart/usr/bin/docker compose up -d --remove-orphans ExecStop/usr/bin/docker compose down StandardOutputjournal [Install] WantedBymulti-user.target然后启用服务sudo systemctl daemon-reload sudo systemctl enable postgres-main sudo systemctl start postgres-main这样整条依赖链就清晰了系统启动 - Docker 启动 - compose 服务拉起来。日常维护时你既可以用docker compose操作也可以用systemctl stop postgres-main优雅关停容器。为什么我坚持加这一层 systemd因为我在实际生产环境遇到过 Docker daemon 起来了但容器没有恢复的怪事查了半天最后发现是某个数据卷挂载点还没 ready容器启动就失败了。systemd 的Afternetwork-online.target和Requiresdocker.service可以很大程度规避这种顺序问题。4.4 安全加固账号、密码、网络三层防护数据库安全这事很多人觉得“我密码够复杂就行”实际上远远不够。我总结了三层防护原则第一层账号密码。POSTGRES_PASSWORD一定不要用弱密码也不要直接写在博客、公司文档里。建议用密码管理器生成 20 位以上的随机密码并定期轮换。如果 compose 文件在 git 仓库里务必将密码改成从环境变量读取例如${POSTGRES_PASSWORD}然后通过.env文件或 CI 密钥管理注入。第二层网络隔离。PostgreSQL 的 5432 端口尽量不要暴露到公网。现实中有大量案例是开发图省事把 5432 映射为0.0.0.0:5432然后被扫描器爆破成功。如果确实需要远程连接我建议通过腾讯云安全组限制来源 IP或者走内网、SSH 隧道、堡垒机方式访问。第三层PostgreSQL 内部访问控制。容器默认配置的pg_hba.conf对本地连接比较宽松我要强调一个 PostgreSQL 15 的变化默认认证方式改成了scram-sha-256这比旧版的md5更安全但如果你是从 PostgreSQL 14 或更早版本迁移过来的客户端驱动版本太旧时可能会出现认证失败。建议所有连接都显式使用scram-sha-256不要退回md5。我还有一个习惯在腾讯云安全组里把 5432 只对需要的来源 IP 放行同时在云服务器本机防火墙iptables/ufw也做同样限制。双重保险即使安全组配置被误改本机防火墙还能兜底。5. 常见问题与排查实录5.1 端口连不上先按这个顺序排查遇到“数据库连不上”的情况99% 都逃不过下面这几个问题。我给你的排查路径是自下而上的容器是否还在运行docker ps如果容器 NOT RUNNING看日志docker logs postgres-main。端口映射是否存在docker port postgres-main或者用ss -lntp | grep 5432看宿主机端口是否在监听。腾讯云安全组是否放行控制台检查入站规则很多新手在这里卡半小时。PostgreSQL 监听地址是否正确官方镜像默认监听所有地址listen_addresses *如果你自己改了配置仔细检查。认证是否通过看容器日志里有没有password authentication failed如果有去核对密码和 pg_hba.conf 规则。我遇到过最典型的一个情况是安全组放行了 5432宿主机ss也看到监听但业务侧还是连接超时。最后发现是腾讯云控制台里服务器绑定了多个安全组两个安全组规则叠加后较严格的组把 5432 拦截了。排查这类问题时建议在腾讯云控制台的“安全组”页面把规则的来源、端口、协议逐条核对而不是只看默认组。5.2 修改 POSTGRES_PASSWORD 为什么不生效很多人在容器启动后想改密码直接编辑 compose 文件的POSTGRES_PASSWORD再docker compose up -d结果发现密码没变。这是因为POSTGRES_PASSWORD环境变量只在“数据目录首次初始化”时生效数据文件一旦生成密码就固化在数据库里了之后修改环境变量不会改变已有密码。正确改密码的方式有两个方式一进入容器用 SQL 修改docker exec -it postgres-main psql -U appuser -d appdb ALTER USER appuser WITH PASSWORD 新密码;方式二更推荐的做法是使用 PostgreSQL 的pgpass文件或单独维护一个运维账号避免频繁在命令行明文传密码。日常我正在用的是把密码存到容器外的.pgpass文件中权限设为 600逻辑上比较安全。如果你确实想换用户比如从 appuser 换成一个新的用户名注意一个是修改数据目录权限另一个是重新授权数据库对象属主。这个操作比改密码复杂建议先在测试环境演练一遍。5.3 容器数据权限导致的 Permission Denied初始化数据目录时PostgreSQL 官方镜像会使用postgres用户UID 999写数据。如果你把宿主机目录挂载进去时目录属主不对容器就会报类似chmod: changing permissions of /var/lib/postgresql/data: Operation not permitted或者could not open file ... Permission denied的错误。解决方法是在宿主机把数据目录属主改成 999sudo chown -R 999:999 /data/postgres/data注意改了属主之后宿主机上的 deploy 用户可能就不能直接读写数据文件了。这其实是好事情——数据库文件本来就不应该被普通用户随意改动备份时用 docker exec 里的工具或者提前把 deploy 用户加入一个可以读数据目录的辅助组。如果你确实想让某个宿主机用户直接管理数据目录可以在 compose 里指定user: 1000:1000之类的用户映射但这样做要确保容器内进程权限能正常写文件不建议新手折腾。5.4 关于 PostgreSQL 和 MySQL 的选择在部署过程中我经常被问到“为什么不直接用 MySQL你们公司不都用 MySQL 吗”。我的观点是PostgreSQL 和 MySQL 都是优秀的开源数据库但适用场景有差异。PostgreSQL 在复杂查询、窗口函数、CTE公共表表达式、JSONB 支持、地理空间数据PostGIS等方面表现更优秀而且在数据完整性约束、并发控制上做得更严格。MySQL 的优势在于生态极其成熟、运维资料多、云厂商托管选项多在简单的 CRUD 业务和高并发读场景下也很能打。如果你选 PostgreSQL那就把它的特性利用起来比如用 JSONB 替代一部分文档数据库需求、用LATERAL JOIN简化复杂子查询、用生成列维护数据一致性。这和使用 Docker 部署没有冲突反而因为部署变得简单你可以更大胆地去尝试这些高级特性。5.5 常见问题速查表现象可能原因快速处理容器反复重启数据目录权限错误或磁盘满docker logs看具体错误df -h检查磁盘连接时报 password authentication failed密码错误、pg_hba.conf 类型不匹配核对密码和认证方式PostgreSQL 15 用 scram-sha-256宿主机能连外部连不上安全组/防火墙问题检查腾讯云安全组和本机防火墙定时备份没有生成文件crontab 路径问题、脚本权限不足手动执行脚本看报错crontab -l检查定时任务是否安装明明数据写入成功数据文件却不在宿主机目录volume 路径写错检查 compose 文件确认宿主机绝对路径是否挂在正确位置容器日志不滚动容器日志未配置 max-size在 compose 中设置 logging.driver.options重启容器生效写在最后的个人体会这套方案我在腾讯云 Ubuntu 24.04 上已经稳定运行了挺长时间从测试环境一路推到生产整体感触是用 Docker 跑 PostgreSQL 最大的好处不是“省事”而是让数据库变成了一种可复制的组件。新环境部署从原来的“照着文档手动装”变成“复制 compose 文件、改一下目录和密码、几秒钟起一个实例”。升级数据库版本也从“备份、停服、apt 升级、验证”变成“换镜像 tag、拉新镜像、切容器”。这种体验一旦习惯了就再也不想回到手工装包的老路上。当然容器化数据库并不是银弹。如果业务达到了千万级日活、数据库要跑 TPCC 基准、或者有非常严格的数据持久化审计要求我更建议使用云厂商的托管数据库服务或者把 Kubernetes StatefulSet 和持久化存储那套体系研究透了再说。但在绝大多数业务体量下Docker 部署 PostgreSQL 已经完全够用而且能让你把更多精力放在业务本身。最后再分享一个小技巧数据库容器尽量只在安全组内网访问任何对公网开放的数据库端口都是在给自己埋雷能不开就别开。