news 2026/8/16 6:34:00

Redis Stack 部署与核心功能实战指南：从Docker安装到生产环境优化

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Redis Stack 部署与核心功能实战指南：从Docker安装到生产环境优化

1. 项目概述：为什么选择Redis Stack？

如果你正在寻找一个既能当缓存，又能当数据库，还能处理JSON文档、全文搜索和时序数据的“瑞士军刀”，那Redis Stack可能就是你的答案。它不是一个全新的产品，而是将Redis核心与一系列强大的扩展模块（RedisJSON, RedisSearch, RedisTimeSeries, RedisGraph, RedisBloom）打包在一起的开箱即用解决方案。简单来说，它让Redis从一个单纯的内存键值存储，进化成了一个功能全面的实时数据平台。

我最初接触Redis Stack，是因为一个需要实时推荐和复杂查询的微服务项目。传统的“Redis + 独立搜索引擎/数据库”架构，在数据同步延迟和运维复杂度上让我头疼不已。Redis Stack的出现，让我能在同一个数据层里完成数据存储、复杂查询和实时分析，极大地简化了架构。对于需要快速原型验证、构建实时应用（如实时仪表盘、聊天应用、物联网数据处理）或者希望简化技术栈的团队来说，部署和使用Redis Stack是一个极具性价比的起点。它特别适合开发者、架构师以及DevOps工程师，无论你是想本地开发测试，还是准备将其用于生产环境，这份从部署、安装到核心使用的说明，都将基于我多次实战的经验，带你避开我踩过的那些坑。

2. 部署方案选型与核心思路

部署Redis Stack，你面前通常有两条主流路径：使用Docker容器化部署，或者在物理机/虚拟机上直接安装。选择哪种方式，取决于你的使用场景、团队技术栈和运维习惯。

2.1 Docker部署：敏捷与隔离的首选

对于绝大多数开发、测试环境，以及追求快速一致性的生产环境，Docker部署是我的首选推荐。它的核心优势在于环境隔离和可重复性。你不需要关心宿主机操作系统的版本差异（是Ubuntu 22.04还是CentOS 7），一个docker run命令就能在任何支持Docker的机器上拉起一个功能完全相同的Redis Stack实例。

为什么选择Docker？

  1. 一致性：镜像包含了所有依赖和模块，确保“在我机器上能跑，在你机器上也能跑”。
  2. 快速启停：秒级启动和销毁，非常适合需要频繁创建临时环境进行功能验证或集成测试的场景。
  3. 资源隔离：可以方便地限制CPU和内存使用，避免单个服务耗尽主机资源。
  4. 与微服务架构天然契合：如果你的项目本身就是基于Docker和Kubernetes的，那么将Redis Stack作为其中一个服务进行编排和管理会非常顺畅。

潜在考量：对于性能极度敏感、需要极致磁盘I/O（虽然Redis主要是内存操作，但持久化时涉及磁盘）的场景，或者宿主机环境非常单一且固定的传统部署模式，直接安装可能更有吸引力。但就通用性而言，Docker方案的优势是压倒性的。

2.2 直接安装：追求极致控制

直接安装在Linux服务器上，意味着你需要手动处理所有依赖、下载二进制包或从源码编译。这种方式让你对安装路径、配置文件位置、服务管理方式（systemd vs init.d）拥有完全的控制权。

适合直接安装的场景：

  • 对宿主机环境有深度定制，且不希望引入容器化层。
  • 运维团队对传统服务管理流程有严格要求。
  • 需要将Redis Stack紧密集成到现有的、非容器化的监控和备份体系中。

核心挑战：你需要自行确保系统满足所有模块的依赖（比如某些模块可能需要较新版本的GCC或特定的系统库），并且不同Linux发行版的安装步骤可能有差异，增加了运维复杂度。

注意：无论选择哪种方式，在生产环境部署前，请务必在隔离的测试环境中进行完整的验证，包括数据持久化、故障恢复、性能压测和安全配置。

3. 两种部署方式的详细实操指南

接下来，我将分别详细拆解Docker部署和Linux直接安装的每一步。我会以最常用的方式为例，并附上关键配置的解读和避坑点。

3.1 基于Docker的部署实操

假设你已经在目标机器上安装好了Docker和Docker Compose。我们使用官方提供的redis/redis-stack镜像。

3.1.1 使用Docker Run快速启动

最简单的单机运行命令如下：

docker run -d --name redis-stack -p 6379:6379 -p 8001:8001 redis/redis-stack:latest
  • -d：后台运行。
  • --name redis-stack：为容器指定一个名字，方便管理。
  • -p 6379:6379：将容器的Redis端口（默认6379）映射到宿主机的6379端口。这是你用redis-cli或其他客户端连接时使用的端口。
  • -p 8001:8001：将容器的RedisInsight管理界面端口（默认8001）映射到宿主机的8001端口。RedisInsight是Redis官方提供的图形化管理工具，内置于Redis Stack中，非常方便。
  • redis/redis-stack:latest：指定使用的镜像。生产环境强烈建议使用特定版本标签（如redis/redis-stack:7.2.0-v10），而非latest，以保证版本稳定性。

执行后，访问http://你的服务器IP:8001，就能看到RedisInsight的欢迎界面，进行可视化操作了。

3.1.2 使用Docker Compose定义复杂服务

对于需要定义数据卷、网络、资源限制等复杂配置的场景，使用docker-compose.yml文件是更规范的做法。

创建一个docker-compose.yml文件，内容如下：

version: '3.8' services: redis-stack: image: redis/redis-stack:7.2.0-v10 # 指定版本 container_name: my-redis-stack restart: unless-stopped # 容器退出时自动重启（除非手动停止） ports: - "6379:6379" - "8001:8001" volumes: - ./redis-data:/data # 将数据目录挂载到宿主机，实现数据持久化 - ./redis-stack.conf:/redis-stack.conf # 挂载自定义配置文件 command: redis-stack-server /redis-stack.conf # 使用自定义配置启动 environment: - REDIS_ARGS=--requirepass yourStrongPasswordHere # 通过环境变量设置密码（方式之一） # 资源限制示例 deploy: resources: limits: memory: 2G cpus: '1.0'

关键配置解析与避坑：

  1. 数据持久化（volumes）：- ./redis-data:/data这一行至关重要。它将容器内的/data目录（Redis持久化文件默认存放处）挂载到宿主机的当前目录下的redis-data文件夹。这样即使容器被删除，数据也不会丢失。务必确保宿主机目录存在且具有正确的写权限。
  2. 自定义配置（volumes&command）：我们挂载了一个本地的redis-stack.conf配置文件，并通过command指定使用它启动。这允许你进行深度定制，比如调整内存策略、开启AOF持久化、设置慢查询日志等。如果不需要复杂配置，可以删除这两行，容器会使用默认配置。
  3. 设置密码：示例中通过REDIS_ARGS环境变量传递--requirepass参数来设置密码。这是一种方式，但密码会明文出现在Compose文件中。更安全的生产环境做法是：使用Docker secrets、在自定义配置文件中设置密码，或者通过运行时环境变量文件（env_file）来管理敏感信息。
  4. 资源限制（deploy.resources）：在docker-compose.yml中，deploy部分通常在Swarm模式下生效。对于单纯的docker-compose up，你可以使用mem_limit和cpus等旧标签，或者直接在docker run中使用-m和--cpus参数。限制资源可以防止Redis占用过多内存导致宿主机OOM（内存溢出）。

保存文件后，在同一个目录下执行docker-compose up -d即可启动服务。

3.2 在Linux系统上直接安装

这里以Ubuntu 22.04 LTS为例，演示通过官方仓库安装。其他发行版（如CentOS/RHEL）步骤类似，主要是包管理工具和仓库添加命令不同。

3.2.1 通过APT仓库安装（推荐）

这是最简洁的安装方式，便于后续升级。

# 1. 导入Redis Stack的GPG密钥，用于验证软件包 curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg # 2. 添加Redis Stack的APT仓库 echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list # 3. 更新包列表并安装Redis Stack sudo apt-get update sudo apt-get install redis-stack-server

安装完成后，Redis Stack服务会自动启动。你可以使用以下命令管理服务：

sudo systemctl status redis-stack-server # 查看状态 sudo systemctl start redis-stack-server # 启动 sudo systemctl stop redis-stack-server # 停止 sudo systemctl enable redis-stack-server # 设置开机自启

3.2.2 核心目录与文件说明安装完成后，你需要了解几个关键路径：

  • 配置文件：/etc/redis-stack/redis-stack.conf。这是主配置文件，所有持久化、内存、模块加载等设置都在这里。
  • 数据目录：/var/lib/redis-stack。RDB和AOF持久化文件默认存储在这里。
  • 日志文件：/var/log/redis-stack/redis-stack-server.log。运行日志和错误信息在这里查看。
  • 可执行文件：/opt/redis-stack/bin/。包含了redis-cli、redis-benchmark等工具。

3.2.3 基础安全与配置调整安装后第一件事就是修改默认配置，尤其是生产环境。

  1. 设置密码：编辑/etc/redis-stack/redis-stack.conf，找到# requirepass foobared这一行，取消注释并将foobared替换成你自己的强密码。
    requirepass YourSuperStrongPassword123!
  2. 绑定地址：默认配置bind 127.0.0.1只允许本地连接。如果你需要从其他服务器访问，可以改为bind 0.0.0.0（监听所有网卡），但务必配合防火墙和密码确保安全。更安全的做法是绑定到内网IP，如bind 192.168.1.100 127.0.0.1。
  3. 重启服务生效：
    sudo systemctl restart redis-stack-server

4. 核心功能模块初体验与基本使用

部署成功后，让我们快速上手Redis Stack的核心增值功能。我们将使用redis-cli（命令行工具）和RedisInsight（图形化工具）进行演示。

4.1 连接与验证

首先，用redis-cli连接并认证（如果设置了密码）：

# 连接本地服务器 redis-cli # 如果设置了密码，连接后需要认证 AUTH yourPassword # 或者连接时直接指定密码（注意：密码可能出现在进程列表里） redis-cli -a yourPassword

输入PING，如果返回PONG，说明连接成功。

4.2 RedisJSON：像操作对象一样处理JSON

传统Redis的String类型存储JSON字符串，读写时需要序列化和反序列化。RedisJSON模块允许你直接以JSON格式存储、访问和修改文档中的特定字段。

# 1. 存储一个完整的JSON文档 JSON.SET user:1000 . '{"name":"Alice","age":30,"city":"London","hobbies":["reading","hiking"]}' # 2. 获取整个文档 JSON.GET user:1000 # 3. 仅获取特定字段（高效！） JSON.GET user:1000 .name JSON.GET user:1000 .hobbies # 4. 更新特定字段，无需读取整个文档 JSON.SET user:1000 .age 31 JSON.ARRAPPEND user:1000 .hobbies '"gaming"' # 向数组追加元素 # 5. 数字运算 JSON.NUMINCRBY user:1000 .age 1

实操心得：在需要频繁更新用户画像、商品属性等半结构化数据的场景，RedisJSON能极大减少网络传输和数据序列化开销。但要注意，复杂的嵌套查询不是它的强项，那是RedisSearch的领域。

4.3 RedisSearch：强大的全文与二级索引

这是我最常用的模块。它让你能在Redis数据上创建索引，执行复杂的查询、过滤、排序和聚合，支持中文分词（需配置）。

# 假设我们有一些文章数据 JSON.SET article:1 . '{"title":"Redis Stack 入门指南","content":"这是一篇关于部署和使用Redis Stack的详细教程。","author":"老王","tags":["redis","database","tutorial"],"views":1500}' JSON.SET article:2 . '{"title":"微服务架构设计","content":"探讨如何利用Redis作为微服务间的缓存和数据网格。","author":"小李","tags":["microservice","architecture"],"views":3200}' # 1. 在JSON文档的特定字段上创建索引 FT.CREATE idx:article ON JSON PREFIX 1 article: SCHEMA $.title AS title TEXT $.content AS content TEXT $.author AS author TAG $.tags AS tags TAG SORTABLE $.views AS views NUMERIC SORTABLE # 2. 全文搜索：在标题和内容中查找“Redis” FT.SEARCH idx:article "Redis" # 3. 过滤与排序：查找标签包含“database”且浏览量大于1000的文章，按浏览量降序排列 FT.SEARCH idx:article "@tags:{database} @views:[1000 +inf]" SORTBY views DESC # 4. 聚合：按作者统计文章总浏览量 FT.AGGREGATE idx:article "*" GROUPBY 1 @author REDUCE SUM 1 @views AS total_views

注意：创建索引需要仔细设计SCHEMA，定义字段类型（TEXT, TAG, NUMERIC等）。错误的类型定义会导致查询失败或性能低下。对于生产环境，建议先在测试环境充分验证索引设计。

4.4 RedisTimeSeries：高效处理时序数据

专门为时间序列数据优化，支持降采样、聚合查询和压缩，非常适合监控指标、物联网传感器数据。

# 1. 创建一个时间序列，设置标签用于过滤 TS.CREATE temperature:sensor:1 LABELS sensor_id 1 location "server_room" # 2. 添加数据点（时间戳自动生成） TS.ADD temperature:sensor:1 * 23.5 # * 表示使用当前服务器时间(毫秒) # 或指定时间戳 TS.ADD temperature:sensor:1 1715000000000 24.1 # 3. 范围查询 TS.RANGE temperature:sensor:1 1715000000000 1715086400000 # 4. 聚合查询：查询最近一小时内，每5分钟的平均温度 TS.RANGE temperature:sensor:1 - 3600000 AGGREGATION avg 300000

避坑技巧：频繁插入单个数据点可能产生性能开销。如果数据产生速率极高，考虑在客户端进行批量聚合，再以较低的频率写入，或者使用TS.MADD命令进行批量添加。

4.5 使用RedisInsight进行可视化操作

图形化界面能极大提升效率。访问http://localhost:8001进入RedisInsight。

  1. 添加数据库：首次进入需要添加连接，输入主机、端口、密码（如果有）。
  2. 浏览数据：左侧浏览器可以按键模式查看所有数据，支持树状视图。
  3. 执行命令：内置了CLI界面，支持命令补全和高亮，比终端更友好。
  4. 内存分析：可以直观地查看内存使用情况，找出大Key。
  5. 慢查询日志：直接查看和分析慢查询，帮助性能优化。
  6. 模块支持：对于RedisJSON和RedisSearch，提供了专用的交互界面，可以方便地创建索引、执行查询，无需记忆命令语法。

对于不熟悉命令的团队成员，或者需要进行数据探索和临时查询时，RedisInsight是一个不可或缺的工具。

5. 生产环境关键配置与优化建议

将Redis Stack用于生产环境，绝不能仅满足于“跑起来”。以下配置和优化点来自实际运维中的经验总结。

5.1 持久化策略：RDB与AOF的权衡

Redis提供两种持久化方式，理解其原理并合理配置是数据安全的基础。

  • RDB (快照)：在指定时间间隔内，生成数据集的时间点快照。文件紧凑，恢复速度快。但可能会丢失最后一次快照之后的所有数据。
  • AOF (追加文件)：记录每一个写操作命令，并在重启时重新执行以恢复数据。数据耐久性更高，默认每秒同步一次，最多丢失一秒数据。但文件通常比RDB大，恢复速度慢。

生产环境推荐配置（在redis-stack.conf中修改）：

# 启用AOF appendonly yes appendfilename "appendonly.aof" # AOF策略：每秒同步，在性能和耐久性间取得较好平衡 appendfsync everysec # 同时启用RDB，用于备份和快速恢复 save 900 1 # 900秒内至少有1个key变化，则保存 save 300 10 # 300秒内至少有10个key变化，则保存 save 60 10000 # 60秒内至少有10000个key变化，则保存 dbfilename dump.rdb dir /var/lib/redis-stack # 确保此目录有足够空间且已持久化

策略解读：我们采用了“AOF为主，RDB为辅”的混合策略。appendfsync everysec是生产环境的甜点。同时保留RDB的save规则，可以在需要时获得一个更紧凑的备份文件，并且redis-stack-server在启动时如果发现同时存在AOF和RDB文件，会优先使用AOF文件来恢复数据，因为AOF的数据更完整。

5.2 内存管理与淘汰策略

Redis是内存数据库，必须妥善管理内存，防止写满后导致服务不可用。

# 设置最大内存限制，例如4GB。务必根据系统物理内存设置，留出部分给操作系统和其他进程。 maxmemory 4gb # 设置内存达到上限后的淘汰策略 maxmemory-policy allkeys-lru

淘汰策略选择：

  • volatile-lru：从已设置过期时间的键中，移除最近最少使用的键。这是最常用的策略，如果你能合理设置键的TTL。
  • allkeys-lru：从所有键中移除最近最少使用的键。适用于所有数据都可能被淘汰的场景。
  • volatile-ttl：从已设置过期时间的键中，移除即将过期的键。
  • noeviction：不淘汰，当内存不足时，新写入操作会报错。适用于绝对不能丢失数据的场景，但你必须确保有监控和扩容机制。

实操心得：不要使用allkeys-random或volatile-random，除非你有非常特殊的理由。LRU（最近最少使用）策略在大多数场景下能提供更可预测的性能。同时，务必使用INFO memory命令定期监控used_memory和maxmemory，确保有充足余量。

5.3 安全加固清单

  1. 密码认证：如前述，必须设置强密码（requirepass）。
  2. 禁用高危命令：将不必要或危险的命令重命名或禁用。
    rename-command FLUSHALL "" # 禁用清空所有数据库 rename-command FLUSHDB "" # 禁用清空当前数据库 rename-command CONFIG "" # 禁用在线修改配置（可通过外部文件管理） rename-command SHUTDOWN "" # 慎重考虑，或重命名为一个复杂字符串
  3. 网络层防护：
    • 使用bind指令限制监听IP，仅允许可信网络访问。
    • 配置服务器防火墙（如ufw或firewalld），只开放必要的端口（6379, 8001）。
    • 考虑将Redis服务部署在内网，通过应用服务器代理访问。
  4. 启用保护模式：确保protected-mode yes（默认）。当未设置bind且未设置密码时，此模式会只允许本地回环连接。
  5. TLS加密传输：对于跨公网或高安全要求的环境，配置TLS加密客户端与服务端之间的通信。这需要在配置中指定证书和密钥文件。

6. 监控、维护与故障排查实战

6.1 基础监控指标与命令

运维的眼睛就是监控。除了使用RedisInsight的图形化监控，命令行工具更灵活。

  • 实时状态：INFO命令返回海量信息。重点关注INFO stats（命令统计）、INFO memory（内存使用）、INFO persistence（持久化状态）、INFO replication（主从状态）。
  • 慢查询日志：SLOWLOG GET 10获取最近10条慢查询。慢查询阈值由slowlog-log-slower-than配置（单位微秒，默认10000即10毫秒）。
  • 大Key查找：redis-cli --bigkeys可以扫描并统计大Key。注意：此命令在生产环境可能阻塞服务，请在低峰期使用。
  • 内存分析：对于更细粒度的内存分析，可以使用MEMORY USAGE key命令查看特定Key的内存占用，或使用redis-rdb-tools等第三方工具分析RDB文件。

6.2 常见问题与解决方案速查表

以下是我在运维中遇到的一些典型问题及解决思路：

问题现象可能原因排查命令/步骤解决方案
客户端连接超时或失败1. 服务未启动
2. 防火墙/安全组阻止
3. 密码错误
4.bind配置限制		1.systemctl status redis-stack-server
2.telnet <host> 6379
3. 检查客户端密码
4. 查看配置文件bind项		1. 启动服务
2. 开放防火墙端口
3. 修正密码
4. 调整bind配置或网络策略
内存使用率持续走高，接近maxmemory1. 数据自然增长
2. 内存泄漏（如未设置TTL的临时数据）
3. 淘汰策略配置不当		1.INFO memory查看used_memory
2.redis-cli --bigkeys
3. 分析Key模式和使用TTL key		1. 规划扩容
2. 检查业务代码，为临时数据设置过期时间
3. 调整maxmemory-policy
响应变慢，INFO stats显示instantaneous_ops_per_sec下降1. 慢查询
2. 内存交换（SWAP）
3. 网络问题
4. 持久化阻塞（fork耗时）		1.SLOWLOG GET
2.free -h查看swap使用
3. 网络延迟测试
4. 查看日志是否有Background saving started相关警告		1. 优化慢查询（如为复杂查询创建索引）
2. 增加物理内存，确保vm.overcommit_memory=1
3. 检查网络
4. 考虑使用更高配置机器，或调整save策略减少fork频率
AOF文件过大长时间运行，写操作积累ls -lh /var/lib/redis-stack/appendonly.aof执行BGREWRITEAOF命令重写AOF文件以压缩体积。可配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size自动触发。
主从复制中断1. 网络中断
2. 主库内存不足导致RDB创建失败
3. 从库写入导致数据不一致		主库：INFO replication
从库：查看日志，INFO replication		1. 恢复网络
2. 主库释放内存或扩容
3. 确保从库为只读模式，并尝试SLAVEOF NO ONE后重新配置复制

6.3 备份与恢复策略

备份：

  1. RDB文件备份：直接复制dump.rdb文件。可以在save间隔期间手动执行SAVE（阻塞）或BGSAVE（后台）命令生成快照后复制。
  2. AOF文件备份：直接复制appendonly.aof文件。由于AOF是追加写入，复制时最好先执行BGREWRITEAOF重写以减小体积。
  3. 自动化备份脚本：结合cron定时任务，在业务低峰期执行redis-cli BGSAVE，然后使用scp或rsync将RDB文件传输到远程备份服务器。

恢复：

  1. RDB恢复：关闭Redis服务，将备份的dump.rdb文件放入配置中dir指定的目录，并确保文件权限正确，然后启动Redis。Redis会自动加载它。
  2. AOF恢复：关闭Redis服务，将备份的appendonly.aof文件放入正确目录，启动Redis。Redis会读取AOF文件中的命令序列来重建数据集。

重要提示：恢复操作前，务必对现有数据目录进行完整备份。恢复后，应使用redis-cli连接并进行数据抽样验证，确保恢复成功。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/8/16 6:32:46

知识付费系统开发如何助力企业打造在线培训平台？

随着企业数字化培训需求不断增加&#xff0c;传统的线下培训方式在课程管理、员工学习、考试考核和培训数据统计等方面逐渐暴露出一些局限。通过开发知识付费系统&#xff0c;可以将企业课程、员工学习、在线考试、培训资料和学习数据集中到一个平台中&#xff0c;为企业建立更…

作者头像 李华
网站建设 2026/8/16 6:25:03

SSL证书部署全指南：从原理到实践，构建网站安全基石

你有没有过这样的经历&#xff1a;打开一个网站&#xff0c;浏览器地址栏突然跳出刺眼的红色警告&#xff0c;告诉你“连接不安全”&#xff1f;或者&#xff0c;在某个需要输入密码的页面&#xff0c;心里总隐隐觉得不踏实&#xff0c;担心自己的信息在传输中被“看光”&#…

作者头像 李华
网站建设 2026/8/16 6:16:54

从PID到模型预测：管道小球摆杆控制的核心难点与工程实现

你有没有遇到过这样的场景&#xff1a;一个看似简单的物理控制问题&#xff0c;比如让小球在管道里滚动&#xff0c;用摆杆去接住它&#xff0c;听起来像是高中物理实验。但当你真正动手&#xff0c;把电机、传感器、控制器和代码都连起来&#xff0c;却发现小球要么滚过头&…

作者头像 李华
网站建设 2026/8/16 6:00:12

RAG 召回率 95% 仍答错：Anthropic 重排机制差点让我交差一份科幻小说

RAG 召回率 95% 仍答错:Anthropic 重排机制差点让我交差一份科幻小说 企业知识库系统的API版本混乱危机:从召回率陷阱到解决方案 事件背景:一个周五下午的技术噩梦 那天下午4点23分,我正在整理本周的技术周报,突然企业Slack频道亮起红色警报--来自某重要客户的紧急投诉。他们…

作者头像 李华
网站建设 2026/8/16 5:56:32

Python包发布全流程指南：从项目打包到PyPI上架

1. 项目概述&#xff1a;为什么要把自己的代码“上架”到PyPI&#xff1f; 如果你写过一些自认为不错的Python工具或库&#xff0c;可能遇到过这样的场景&#xff1a;同事或朋友想用你的代码&#xff0c;你得把整个项目文件夹打个压缩包发过去&#xff0c;对方还得手动安装依赖…

作者头像 李华