1. 项目概述：一个为开发者准备的“开箱即用”部署方案

最近在GitHub上看到一个挺有意思的项目，叫 Goodsmileduck/openclaw-deploy-do 。光看名字，可能有点摸不着头脑，但如果你是一个经常需要部署Web应用、API服务或者小型爬虫的开发者，尤其是对Docker和云服务器操作还不太熟练的朋友，这个项目很可能就是你一直在找的“脚手架”或者“一键部署脚本”。

简单来说，这是一个部署脚本项目。它的核心价值在于， 将一套经过验证的、可靠的服务器应用部署流程，固化成了可重复执行的脚本 。想象一下，你每次拿到一台新的云服务器（比如DigitalOcean的Droplet，这也是项目名中“do”的由来），都要重复安装Docker、Docker Compose、配置防火墙、拉取镜像、编写 docker-compose.yml 文件、设置环境变量……这套流程既繁琐又容易出错。而这个项目，就是帮你把这些琐事自动化，让你能专注于应用本身的开发和业务逻辑。

我花了些时间深入研究了这个仓库的源码和设计思路。它不仅仅是一个简单的 bash 脚本合集，更体现了一种“基础设施即代码”和“不可变基础设施”的运维思想雏形。对于个人开发者、小团队或者需要快速验证原型的情况，这类工具能极大提升效率，降低运维门槛。接下来，我将为你彻底拆解这个项目的设计精髓、实操细节以及如何将其适配到你自己的项目中。

2. 核心设计思路与架构拆解

2.1 定位与解决的核心痛点

在深入代码之前，我们必须先理解它要解决什么问题。 openclaw-deploy-do 的定位非常清晰： 为在DigitalOcean（DO）云服务器上，基于Docker Compose部署应用，提供一套标准化的、可复用的部署流程。

它主要解决了以下几个开发者常见的痛点：

  1. 环境初始化不一致 ：手动配置服务器，每次可能因为疏忽漏掉某个依赖（如 curl ）或配置项（如 ufw 规则），导致环境差异，为后期埋下隐患。
  2. 部署流程碎片化 ：部署步骤分散在笔记、聊天记录或记忆中，缺乏一个统一的、版本化的执行清单。新人接手或自己隔一段时间再操作时，容易遗忘关键步骤。
  3. 敏感信息管理混乱 ：数据库密码、API密钥等敏感信息（ secrets ）可能被硬编码在配置文件中，或者通过不安全的方式传递，存在泄露风险。
  4. 缺乏回滚和版本控制 ：手动部署难以快速回滚到上一个可用版本。部署脚本本身也没有纳入版本管理，无法追溯变更。

这个项目通过将部署流程脚本化，直接回应了这些痛点，目标是实现 一键初始化、可重复部署、配置版本化 。

2.2 技术栈选型与工具链解析

项目采用的技术栈是经过深思熟虑的，在轻量化和功能性之间取得了很好的平衡：

  • 核心运行时：Docker & Docker Compose 。这是现代应用容器化部署的事实标准。Docker保证了应用运行环境的一致性，而Docker Compose则简化了多容器应用（比如一个Web应用配一个PostgreSQL数据库）的定义和管理。选择它们意味着项目兼容几乎任何可以容器化的应用。
  • 部署脚本语言：Bash Shell 。这是所有Linux发行版的“母语”，无需额外安装解释器，通用性极强。虽然不如Python或Go功能强大，但对于执行一系列系统命令、安装软件包、操作文件这类任务，Bash脚本是最直接、最轻量的选择。
  • 配置管理：环境变量文件（.env） 。这是管理配置和敏感信息的经典模式。项目通常会提供一个 .env.example 模板，用户复制并填写自己的实际值。脚本和 docker-compose.yml 文件通过引用这些环境变量来动态生成配置，实现了代码和配置的分离。
  • 可选组件：Traefik 。在一些更复杂的示例或变体中，可能会集成Traefik作为反向代理和负载均衡器。这对于需要暴露多个Web服务、自动管理SSL证书（Let‘s Encrypt）的场景非常有用，体现了项目对生产环境友好性的考虑。

这个工具链的选择，确保了项目本身依赖极少，学习曲线平缓，同时又能覆盖从简单到相对复杂的部署场景。

2.3 项目目录结构与文件职责

一个典型的 openclaw-deploy-do 风格的项目目录结构可能如下所示（根据具体实现略有不同）： 

openclaw-deploy-do/
├── deploy.sh              # 主部署脚本，核心入口
├── docker-compose.yml     # Docker Compose服务定义模板
├── .env.example           # 环境变量配置模板
├── scripts/               # 子脚本目录，模块化分解任务
│   ├── 01_setup_system.sh    # 系统初始化：更新、安装基础工具
│   ├── 02_install_docker.sh  # 安装Docker引擎和Compose
│   ├── 03_configure_firewall.sh # 配置防火墙规则
│   └── 04_deploy_app.sh       # 拉取镜像、启动容器
└── README.md              # 项目说明、使用指南

各文件的核心职责：

  • deploy.sh ：这是总指挥。它可能按顺序调用 scripts/ 目录下的各个子脚本，并处理一些全局逻辑，如检查当前用户权限、提示用户填写 .env 文件等。它的存在让用户只需要记住并执行这一个命令。
  • docker-compose.yml ：定义了要运行哪些服务（容器）、它们的镜像、端口映射、数据卷挂载、环境变量依赖以及服务间的网络关系。这是应用架构的蓝图。
  • .env.example 与 .env ：前者是模板，列出了所有需要配置的变量及其说明。用户需要复制它为 .env 并填入实际值。 .env 文件通常被 .gitignore 排除，确保密码等不会提交到代码库。
  • scripts/ 下的子脚本：体现了“单一职责”原则。每个脚本只做一件事，并且做好。这样便于调试、复用和修改。例如， 01_setup_system.sh 可以独立运行来准备一台干净的服务器。
  • README.md ：项目的门面。优秀的README应该清晰说明项目目的、快速开始步骤、配置详解、常见问题，这是项目是否易于使用的关键。

3. 核心脚本功能深度解析

3.1 系统初始化与依赖安装

这是部署的基石。 01_setup_system.sh 和 02_install_docker.sh 脚本负责将一台裸机状态的Linux服务器，准备成可以运行容器化应用的环境。

一个健壮的初始化脚本通常会做以下几件事：

  1. 权限检查 ：脚本开头往往会检查是否以 root 用户或拥有 sudo 权限的用户运行。因为安装软件、修改系统配置需要高级权限。 
    #!/bin/bash
if [[ $EUID -ne 0 ]]; then
   echo "此脚本必须以root权限运行。请使用 sudo。" 
   exit 1
fi
  2. 系统更新 ：更新软件包列表并升级已安装的包，确保系统安全性和稳定性。 
    apt-get update && apt-get upgrade -y

    注意 ：在生产环境中，对于无交互的脚本，使用 -y 参数自动确认是必要的。但对于主要版本升级，可能需要更谨慎的策略。

  3. 安装基础工具 ：安装后续脚本或日常维护所需的工具，如 curl , wget , git , vim , ufw （防火墙）等。 
    apt-get install -y curl wget git vim ufw
  4. 安装Docker ：这里通常不会使用系统自带的旧版本Docker包。而是采用Docker官方提供的安装脚本或添加Docker的APT仓库来安装最新稳定版。脚本需要处理不同Linux发行版（如Ubuntu, Debian, CentOS）的差异。 
    # 示例：使用Docker官方便捷脚本安装（适用于快速测试，生产环境建议使用仓库安装）
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
  5. 安装Docker Compose ：同样，从GitHub Release页面下载最新版的Docker Compose二进制文件。这里需要注意架构（x86_64, aarch64）匹配。 
    # 下载特定版本的Docker Compose
COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep 'tag_name' | cut -d\" -f4)
curl -L "https://github.com/docker/compose/releases/download/${COMPOSE_VERSION}/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
  6. 配置非root用户使用Docker（可选但推荐） ：为了避免每次使用 docker 命令都要加 sudo ，可以将当前用户加入 docker 用户组。 
    usermod -aG docker $SUDO_USER
echo "请注销并重新登录，以使docker组权限生效。"

实操心得 ：在编写这类脚本时，一定要加入 set -e 命令（在脚本开头），这样当任何一行命令执行失败（返回非零状态码）时，脚本会立即退出，避免在错误的状态下继续执行。同时，使用 set -x 或在关键命令前加 echo 可以输出执行日志，便于调试。

3.2 安全加固与防火墙配置

安全是部署中不可或缺的一环。 03_configure_firewall.sh 脚本负责此任务。对于面向公网的服务器，仅开放必要的端口是基本原则。

典型的防火墙配置流程：

  1. 启用UFW（Uncomplicated Firewall） ：UFW是Ubuntu/Debian上简化了的 iptables 前端，易于使用。 
    ufw --force enable # 启用防火墙
  2. 设置默认策略 ：最好的安全实践是“默认拒绝”，即关闭所有传入连接，仅开放明确允许的端口。 
    ufw default deny incoming
ufw default allow outgoing
  3. 开放必要端口 ：
    • SSH (22) : 这是你管理服务器的生命线，必须开放，但强烈建议改为非标准端口并配合密钥登录。
    • HTTP (80) / HTTPS (443) : 如果你的应用是Web服务。
    • 应用特定端口 ：例如，你的API服务内部可能监听在3000端口（通过Docker映射到主机的某个端口）。 
    ufw allow 22/tcp comment 'SSH Access'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
# 假设你的docker-compose.yml中将容器端口3000映射到了主机端口8080
ufw allow 8080/tcp comment 'My App API'
  4. 查看并确认规则 ： 
    ufw status numbered

重要注意事项 ：在远程服务器上配置防火墙时， 务必先开放SSH端口，再启用防火墙 ，否则你可能会立刻把自己锁在服务器外面。一个常见的保险做法是在脚本中先添加SSH规则，再 enable UFW。更好的做法是，在云服务商的控制台（如DigitalOcean的控制面板）保留一个“后门”防火墙规则组，这样即使服务器层面的防火墙配置错误，你仍然可以通过云控制台恢复访问。

3.3 Docker Compose部署与应用启动

这是画龙点睛的一步。 04_deploy_app.sh 脚本利用前面准备好的环境，真正拉起你的应用。

这个脚本的核心任务包括：

  1. 加载环境变量 ：确保 .env 文件存在，并将其中的变量导入当前shell环境，供 docker-compose.yml 使用。 
    if [ ! -f .env ]; then
    echo "错误：未找到 .env 配置文件。请基于 .env.example 创建。"
    exit 1
fi
# 加载环境变量，并导出（使其在子shell中可用）
set -a; source .env; set +a
  2. 拉取Docker镜像 ：从Docker Hub或私有仓库拉取服务所需的镜像。使用 docker-compose pull 可以并行拉取所有在 compose 文件中定义的服务镜像。 
    docker-compose pull
  3. 启动/更新服务 ：使用 docker-compose up -d 在后台启动所有服务。 -d 代表“detached”模式。一个更健壮的做法是使用 docker-compose up -d --remove-orphans ，它会移除旧的、未被定义的容器。 
    docker-compose up -d --remove-orphans
  4. 查看服务状态 ：启动后，立即检查容器是否正常运行。 
    docker-compose ps
docker-compose logs --tail=50 [service-name] # 查看某个服务的最近日志
  5. 健康检查与等待（高级） ：对于有依赖关系的服务（如应用依赖数据库初始化完成），脚本可以加入简单的等待循环，检查某个服务的健康接口或日志关键词，确保服务就绪后再进行下一步。 
    echo "等待应用服务就绪..."
for i in {1..30}; do
    if curl -s -f http://localhost:${APP_PORT}/health > /dev/null; then
        echo "应用服务已就绪！"
        break
    fi
    echo "等待中... ($i/30)"
    sleep 2
done

一个关键的细节是 docker-compose.yml 的编写艺术 。在 openclaw-deploy-do 这类项目中，它通常是一个高度参数化的模板： 

version: '3.8'
services:
  webapp:
    image: ${APP_IMAGE:-yourusername/your-webapp:latest}
    container_name: ${APP_CONTAINER_NAME:-my_webapp}
    restart: unless-stopped
    ports:
      - "${HOST_PORT:-8080}:3000"
    environment:
      - DATABASE_URL=postgresql://${DB_USER}:${DB_PASSWORD}@db:5432/${DB_NAME}
      - REDIS_URL=redis://redis:6379
    depends_on:
      - db
      - redis
    volumes:
      - ./app_logs:/var/log/app
    networks:
      - app_network

  db:
    image: postgres:15-alpine
    container_name: ${DB_CONTAINER_NAME:-my_postgres}
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: ${DB_NAME}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - app_network

  redis:
    image: redis:7-alpine
    container_name: ${REDIS_CONTAINER_NAME:-my_redis}
    restart: unless-stopped
    networks:
      - app_network

volumes:
  postgres_data:

networks:
  app_network:
    driver: bridge

可以看到，几乎所有可能变化的配置（镜像名、容器名、端口、密码）都通过环境变量 ${VAR_NAME} 来引用，并提供了默认值 ${VAR_NAME:-default_value} 。这使得同一份 docker-compose.yml 文件可以通过不同的 .env 文件，轻松部署到开发、测试、生产等不同环境。

4. 完整部署流程实操演练

假设我们现在有一台全新的DigitalOcean Ubuntu 22.04 Droplet，IP地址为 your_server_ip ，我们需要使用 openclaw-deploy-do 风格的项目来部署一个简单的Node.js API应用。

4.1 前期准备与服务器连接

  1. 本地准备 ：将你的部署项目克隆到本地，并准备好你的应用代码和Dockerfile。 
    git clone <your-application-repo>
cd your-application
# 假设你的部署脚本项目是另一个repo，或者放在同一repo的deploy目录下
git clone <openclaw-deploy-do-style-repo> deploy
cd deploy
  2. 配置环境变量模板 ：复制 .env.example 为 .env ，并用你喜欢的编辑器（如 vim , nano ）打开进行配置。 
    cp .env.example .env
vim .env
    你需要填写的内容通常包括： 
    # 服务器和域名设置
SERVER_IP=your_server_ip
DOMAIN_NAME=api.yourdomain.com (如果适用)

# 应用配置
APP_IMAGE=your-dockerhub-username/your-node-app:latest
APP_CONTAINER_NAME=production_api
HOST_PORT=80
CONTAINER_PORT=3000

# 数据库配置
DB_USER=api_user
DB_PASSWORD=$(openssl rand -base64 32) # 强烈建议用命令生成强密码
DB_NAME=api_production

# 其他服务配置...

    安全提示 ：像 DB_PASSWORD 这样的敏感信息，可以使用 openssl rand -base64 32 命令在本地生成一个强随机字符串填入。切勿使用简单密码。

  3. 连接服务器并上传部署文件 ：使用SCP或SFTP工具将整个部署目录（包含脚本、 docker-compose.yml 和配置好的 .env 文件）上传到服务器。 注意， .env 文件包含密码，传输过程建议使用SCP并确保连接安全。 
    # 在本地机器执行
scp -r ./deploy/ root@your_server_ip:/root/
  4. 登录服务器 ： 
    ssh root@your_server_ip
cd /root/deploy

4.2 分步执行部署脚本

现在，我们已经在服务器上的部署目录中。根据项目的设计，你可以选择：

  • 全自动方式 ：如果存在一个 deploy.sh 主脚本，通常只需： 
    chmod +x deploy.sh # 确保脚本有执行权限
./deploy.sh
    这个主脚本会按顺序调用所有子脚本。
  • 分步手动执行（推荐首次部署时，便于调试） ： 
    # 1. 系统初始化
chmod +x scripts/*.sh
./scripts/01_setup_system.sh
# 执行后，系统会更新并安装基础工具。可能需要重启或重新登录以使某些组生效。

# 2. 安装Docker
./scripts/02_install_docker.sh
# 安装完成后，可以运行 `docker --version` 和 `docker-compose --version` 验证。

# 3. 配置防火墙（谨慎！）
# 在执行前，再次确认你的当前SSH连接端口（通常是22）在脚本中被允许。
./scripts/03_configure_firewall.sh
# 执行 `ufw status` 查看规则是否生效。

# 4. 部署应用
./scripts/04_deploy_app.sh
# 脚本会加载.env，拉取镜像，并启动容器。

在执行每一步时，仔细观察终端输出。如果有任何错误（红色文字或非零退出），脚本应该会停止，并根据其设计给出错误提示。

4.3 部署后验证与监控

部署脚本执行完毕后，工作并未结束，必须进行验证。

  1. 检查容器状态 ： 
    docker-compose ps
    你应该看到所有服务（如 webapp , db , redis ）的状态都是 Up 。
  2. 查看应用日志 ： 
    docker-compose logs -f webapp # -f 参数可以持续跟踪日志输出
    查看是否有启动错误，或者应用是否成功监听在预期端口。
  3. 从外部访问测试 ：
    • 如果开放了HTTP端口，直接在浏览器访问 http://your_server_ip （或你映射的端口）。
    • 使用 curl 命令测试API端点： 
      curl http://your_server_ip:${HOST_PORT}/health
    应该收到应用返回的成功响应。
  4. 检查数据持久化 ：如果你的应用使用了数据库，登录到数据库容器内，检查表是否创建成功，或者通过应用写入一些测试数据，然后重启容器，看数据是否还在。 
    docker-compose exec db psql -U ${DB_USER} -d ${DB_NAME}
  5. 设置基础监控（可选但重要） ：可以考虑在服务器上安装一个轻量级的监控工具，如 docker stats 查看容器资源占用，或者使用 cAdvisor 、 Prometheus + Grafana 进行更全面的监控。这可以放在后续的运维脚本中。

5. 常见问题排查与进阶技巧

即使有自动化脚本，在实际操作中依然会遇到各种问题。以下是基于经验的常见问题排查清单和进阶使用技巧。

5.1 部署失败问题速查表

问题现象 可能原因 排查步骤与解决方案
脚本执行权限不足 脚本文件没有执行权限 chmod +x script_name.sh
Docker命令找不到 Docker未成功安装或当前用户不在 docker 组 1. docker --version 验证安装。
2. groups 查看当前用户组，确认包含 docker 。
3. 执行 usermod -aG docker $USER 并 重新登录 。
docker-compose up 报错 .env 文件缺失或变量未定义；镜像拉取失败；端口冲突 1. 确认 .env 文件存在且变量名与 docker-compose.yml 中引用的一致。
2. docker-compose config 检查配置是否有效。
3. docker-compose pull 单独拉取镜像看网络问题。
4. netstat -tulpn | grep :端口号 检查主机端口是否被占用。
容器启动后立即退出 应用本身启动失败；启动命令错误；依赖服务未就绪 1. docker-compose logs [服务名] 查看容器日志，这是最重要的线索。
2. 检查 docker-compose.yml 中该服务的 command 或 entrypoint 是否正确。
3. 检查环境变量是否传递正确，特别是密码等敏感信息。
4. 确认依赖服务（如数据库）的容器是否先于应用启动并健康。
无法从外部访问服务 防火墙未开放端口；Docker网络模式问题；应用监听地址错误 1. ufw status 确认端口已开放。
2. docker-compose ps 查看端口映射是否正确（ 0.0.0.0:主机端口->容器端口 ）。
3. 进入容器内部 docker-compose exec webapp sh ，用 netstat -an 或 curl localhost:容器端口 检查应用是否在容器内正常监听。
4. 确保应用监听的是 0.0.0.0 ，而不是 127.0.0.1 。
数据库连接失败 数据库容器未启动；网络不通；认证信息错误 1. docker-compose ps 确认数据库容器运行中。
2. 从应用容器内尝试连接数据库： docker-compose exec webapp nc -zv db 5432 。
3. 检查 .env 中的数据库连接字符串（用户名、密码、数据库名）是否与数据库容器环境变量设置一致。

5.2 进阶技巧与最佳实践

  1. 使用Makefile作为统一入口 ：对于更复杂的项目，可以考虑使用 Makefile 来管理不同的部署命令（如 make deploy , make logs , make backup ），这比记住一堆 bash 脚本名更友好。 
    .PHONY: deploy logs backup clean
deploy:
    ./scripts/01_setup_system.sh
    ./scripts/02_install_docker.sh
    ./scripts/03_configure_firewall.sh
    ./scripts/04_deploy_app.sh
logs:
    docker-compose logs -f
backup:
    docker-compose exec db pg_dump -U ${DB_USER} ${DB_NAME} > backup_$(date +%Y%m%d).sql
  2. 集成CI/CD管道 ：将这套部署脚本集成到GitHub Actions、GitLab CI或Jenkins中。每次向主分支推送代码时，自动构建Docker镜像、推送到镜像仓库，然后在测试服务器或生产服务器上触发这些部署脚本。这样就将“一键部署”升级为了“无人值守部署”。
  3. 配置管理工具化 ：当服务器数量增多或配置变得极其复杂时，可以考虑使用Ansible、SaltStack或Terraform来替代纯 bash 脚本。它们提供了更强大的状态管理、幂等性和跨平台支持。 openclaw-deploy-do 可以看作是迈向这些专业工具的一个完美起点和学习样板。
  4. 实现蓝绿部署或滚动更新 ：对于追求零宕机的高可用场景，可以扩展你的部署脚本。例如，准备两套相同的环境（蓝和绿），通过更新负载均衡器（如Traefik）的规则，将流量从旧版本（蓝）切换到新版本（绿）。这需要更精细的网络和编排控制，Docker Compose本身支持有限，可能需要结合Docker Swarm或Kubernetes。
  5. 日志与数据持久化策略 ：确保应用日志和数据库数据存储在Docker卷（Volume）或绑定挂载（Bind Mount）的目录中，这样即使容器被删除，数据也不会丢失。在 docker-compose.yml 中明确定义 volumes 部分，并考虑定期备份策略（如上述 make backup 示例）。

5.3 将项目适配到其他云平台

openclaw-deploy-do 虽然名字里带了“do”（DigitalOcean），但其核心思想是通用的。要将其用于AWS EC2、Google Cloud Compute Engine或阿里云ECS，通常只需要修改极少部分：

  1. 防火墙配置 ：不同云厂商的防火墙叫法不同（安全组、防火墙规则、VPC网络规则等）。脚本中的 ufw 部分可能仍然适用（如果使用Ubuntu系统），但 更佳实践是在云控制台配置安全组 ，只开放必要端口。服务器内部的 ufw 可以设置为 allow all 或直接禁用，避免规则冲突。你需要调整 03_configure_firewall.sh 脚本，或者将其替换为云厂商的CLI命令（如 aws ec2 authorize-security-group-ingress ）。
  2. 镜像拉取 ：如果你使用AWS ECR、Google Container Registry等私有仓库，需要在脚本中增加登录私有仓库的步骤。 
    # 例如，对于AWS ECR
aws ecr get-login-password --region region | docker login --username AWS --password-stdin your-account-id.dkr.ecr.region.amazonaws.com
  3. 服务器初始化 ： 01_setup_system.sh 中的包管理命令（ apt-get ）是针对Debian/Ubuntu的。如果目标服务器是CentOS/RHEL系列，需要改为 yum 或 dnf 。可以在脚本开头通过检测发行版来做出条件判断。

本质上，只要你理解了每一段脚本在做什么，就能很容易地将其“翻译”到任何支持Docker的Linux环境中。这种“部署即代码”的思维模式，才是这个项目带给我们的最大价值。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区