1. 项目概述：EJSON的“钥匙”与“门禁”

在数据交换和配置管理的世界里，EJSON（Encrypted JSON）就像是一个带锁的保险箱。它允许你将敏感信息（如API密钥、数据库密码、访问令牌）以加密的形式直接存放在JSON文件中，与代码一同提交到版本控制系统，而无需担心秘密泄露。这个保险箱有两把关键的“钥匙”：一把是用于加密数据的“数据密钥”，另一把是用于解密数据密钥的“公钥/私钥对”。然而，在实际操作中，我们常常会遇到“钥匙丢了打不开箱子”或者“有钥匙但门禁系统不让进”的窘境。前者对应的是密钥丢失或损坏，后者则对应着各种权限错误和环境配置问题。

这篇文章，就是基于我过去几年在多个CI/CD流水线和微服务项目中深度使用EJSON的经验，为你梳理出的10个最实用、最高频的问题解决技巧。无论你是刚刚接触EJSON，还是在部署过程中被某个诡异错误卡住的老手，这里的内容都能帮你快速定位并解决问题。我们会从最让人头疼的密钥丢失开始，一路讲到那些看似是权限问题、实则是环境或配置细节在作祟的“坑”。你会发现，很多问题并非EJSON本身的设计缺陷，而是我们在使用流程和理解上存在盲区。准备好了吗？让我们开始这场“开锁”与“通关”的实战之旅。

2. 核心问题拆解：从密钥生命周期到环境权限

要系统性地解决EJSON的问题，不能头痛医头、脚痛医脚。我们需要理解其核心工作原理和典型故障链。EJSON的工作流可以简化为两个阶段： 加密阶段 和 解密阶段 。绝大多数问题都发生在这两个阶段的交接处。

加密阶段 ：开发者使用一个公开的“公钥”对敏感数据进行加密，生成 .ejson 文件。这个公钥可以安全地分享，因为它只能用于加密，不能解密。此时，对应的“私钥”必须被严格保管，它才是解密的唯一凭证。

解密阶段 ：在需要读取敏感信息的运行时环境（如服务器、CI/CD Agent）中，必须提供对应的“私钥”。EJSON命令行工具或客户端库使用该私钥解密 .ejson 文件，得到明文数据供应用程序使用。

基于这个流程，我们可以把常见问题归为三类：

  1. 密钥管理问题 ：私钥丢失、损坏、格式错误、或未正确传递给解密环境。
  2. 权限与路径问题 ：执行解密的用户或进程没有足够的文件系统权限（读、写、执行），或者EJSON文件、密钥文件的路径引用错误。
  3. 环境与工具问题 ：系统缺少必要的运行时依赖（如 gpg ）、环境变量未设置、或者使用了不兼容的EJSON工具版本。

接下来，我们将针对这三大类问题，展开10个具体的解决技巧。

2.1 技巧一：预防密钥丢失——建立可靠的私钥备份与分发机制

私钥丢失是灾难性的，意味着所有用对应公钥加密的数据都无法恢复。我的第一条建议永远是： 预防优于补救 。

实操方案：分级托管与自动化注入 不要将生产环境的私钥放在任何开发者的本地机器上。我推荐的实践是：

  1. 生成密钥对 ：在安全的、隔离的环境中生成密钥对（例如，一台专门用于密钥管理的跳板机）。
  2. 公钥入仓 ：将公钥（ *.pub ）提交到代码仓库的特定目录（如 /config/ejson/keys ），方便所有开发者使用。
  3. 私钥托管 ：将私钥托管在专业的秘密管理服务中，如HashiCorp Vault、AWS Secrets Manager、Azure Key Vault或GitHub Secrets。 绝对不要 将私钥提交到代码仓库，即使是私有仓库。
  4. 自动化分发 ：在CI/CD流水线（如GitHub Actions, GitLab CI, Jenkins）或部署工具（如Ansible, Terraform）中，通过集成上述秘密管理服务，在运行时动态地将私钥内容注入到运行环境的环境变量或临时文件中。

注意 ：即使托管在云服务中，也建议对私钥本身进行二次加密（例如，用另一个仅限运维人员访问的GPG密钥加密），形成“密钥套密钥”的纵深防御。

如何从备份恢复？ 如果你不幸丢失了私钥，但遵循了上述备份机制，恢复就很简单：从你的秘密管理服务中取出私钥内容，将其设置到目标机器的 EJSON_KEY 环境变量中，或者写入一个文件（如 /tmp/decrypt_key ），然后使用 ejson decrypt --keydir /path/to/keydir 或 ejson decrypt -k /tmp/decrypt_key 来指定密钥进行解密。

2.2 技巧二：诊断与修复损坏或格式错误的私钥

有时私钥文件本身可能因为传输错误（FTP ASCII模式、错误的复制粘贴）、编辑器自动添加换行符或BOM头而损坏。症状通常是 ejson decrypt 命令报出晦涩的加密相关错误，如“解密失败”或“无效的密钥格式”。

诊断步骤：

  1. 检查密钥长度 ：一个标准的Curve25519私钥（EJSON默认使用）应该是44个字符的Base64编码字符串（去尾随换行符）。你可以用命令检查： cat private_key | tr -d '\n' | wc -c 。结果应该是44。
  2. 检查文件编码 ：确保文件是纯文本UTF-8编码，没有BOM。可以使用 file private_key 命令查看，或使用 cat -A private_key 查看是否有不可见字符（如 ^M 代表Windows换行符）。
  3. 验证密钥对 ：如果你还保有公钥，可以用一个快速的方法验证私钥是否有效且匹配。但这通常需要写一小段脚本，利用 ejson 库或 openssl 工具。

修复方案：

  • 移除多余字符 ：使用 tr -d '\n\r' < damaged_key > clean_key 清除换行和回车符。
  • 重新获取 ：最可靠的方法是从你的备份源（秘密管理器）重新获取原始、干净的密钥内容。
  • 重建密钥对 ：如果私钥彻底损坏且无备份，公钥也失效了。这是最坏情况，你必须生成新的密钥对，然后用新公钥重新加密所有 .ejson 文件，并更新所有依赖这些秘密的服务。 这凸显了备份的重要性。

2.3 技巧三：解决“Permission denied”类文件系统权限错误

在Linux/Unix系统上运行 ejson decrypt 时，你可能遇到 Permission denied 错误。这通常不是EJSON本身的问题，而是运行进程的用户对相关文件或目录缺乏权限。

常见场景与排查：

  1. 对.ejson文件无读权限 ：执行解密的用户（如 ci-user ）必须能读取加密的 .ejson 文件。使用 ls -l your_file.ejson 检查权限。如果是 root 创建的，可能需要用 chown 或 chmod 调整。例如： chmod 644 config/secrets.ejson 。
  2. 对密钥文件无读权限 ：如果你通过 --keydir 指定密钥目录或直接使用密钥文件，必须确保该目录或文件对运行用户可读。密钥文件应设置为仅所有者可读（ 600 ）： chmod 600 private_key.pem 。
  3. 对输出目录无写权限 ：如果使用 ejson decrypt 输出解密后的JSON文件，需要确保对输出目录有写权限。
  4. 在容器中运行 ：在Docker容器内运行时，确保通过卷挂载（ -v ）进来的 .ejson 文件和密钥文件在容器内的用户（常常是非root用户）有访问权限。有时需要在宿主机上调整文件权限，或在Dockerfile中用 COPY --chown 指定正确的属主。

一个典型的权限设置示例： 假设你的应用由用户 appuser 运行，项目位于 /opt/myapp 。

# 假设密钥文件从Vault注入到临时位置
echo $EJSON_PRIVATE_KEY > /tmp/temp_key
chmod 600 /tmp/temp_key  # 关键一步：确保仅当前用户可读
chown appuser:appuser /tmp/temp_key

# 切换到应用用户执行解密
sudo -u appuser ejson decrypt -k /tmp/temp_key /opt/myapp/config/secrets.ejson > /opt/myapp/config/secrets.json
# 确保生成的secrets.json也对appuser可读
chown appuser:appuser /opt/myapp/config/secrets.json

解密完成后，应立即安全地擦除 /tmp/temp_key 文件（ shred -u /tmp/temp_key 或 rm -P ）。

2.4 技巧四：正确设置和使用EJSON_KEY环境变量

EJSON_KEY 环境变量是传递私钥最常用、最便捷的方式，尤其是在容器和CI/CD环境中。但这里有几个细节极易出错。

正确格式 ： EJSON_KEY 的值就是私钥的 纯文本内容 ，而不是文件路径。例如：

# 正确做法
export EJSON_KEY="abcd1234...（完整的44字符Base64私钥字符串）"
ejson decrypt config/secrets.ejson

# 错误做法：将路径赋值给变量
export EJSON_KEY="/path/to/private_key"  # 这不会生效！

在CI/CD中注入 ： 以GitHub Actions为例，你在仓库的Secrets中存储了私钥 EJSON_PRIVATE_KEY 。

jobs:
  decrypt:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Decrypt Secrets
        run: |
          echo "${{ secrets.EJSON_PRIVATE_KEY }}" > /tmp/private_key
          chmod 600 /tmp/private_key
          # 方法A：使用临时文件
          ejson decrypt --keydir /tmp config/secrets.ejson
          # 方法B：直接注入环境变量（更安全，不落盘）
          export EJSON_KEY="${{ secrets.EJSON_PRIVATE_KEY }}"
          ejson decrypt config/secrets.ejson > config/secrets.json
        # 注意：GitHub Actions会自动清理运行环境，但显式清除更佳

实操心得 ：我更喜欢 方法B（环境变量） ，因为它避免了在磁盘上留下私钥文件，哪怕只是短暂的一瞬。这对于通过不可信或共享的CI Runner执行任务时，能减少攻击面。

常见陷阱 ：

  • 换行符 ：从某些Web控制台复制粘贴私钥时，可能会无意中添加换行符。确保 echo $EJSON_KEY | wc -c 输出45（44个字符+1个换行），或者使用 export EJSON_KEY="$(cat private_key | tr -d '\n')" 来确保纯净。
  • 作用域 ：在Shell脚本中，确保 export 命令在调用 ejson 的同一个Shell进程或子Shell中。在Makefile或复杂的脚本中，可能需要显式地传递环境变量。

2.5 技巧五：理解并使用--keydir与-k选项的细微差别

ejson 命令行工具提供了两种主要方式来指定私钥： --keydir （或 -d ）和 -k 。理解它们的区别能帮你避免很多困惑。

--keydir 目录模式 ：

  • 用法 ： ejson decrypt --keydir /path/to/keys_dir secrets.ejson
  • 机制 ：EJSON会在指定的目录中查找与 .ejson 文件中 _public_key 字段匹配的 .pub 公钥文件，并尝试使用同名的私钥文件（无扩展名）进行解密。例如，如果 secrets.ejson 的 _public_key 是 abc123.pub ，那么工具会在 /path/to/keys_dir 下寻找 abc123 这个文件（注意没有 .pub 后缀）作为私钥。
  • 适用场景 ：当你管理多个密钥对，并且已经按照“公钥文件名为 <key_id>.pub ，对应私钥文件名为 <key_id> ”的约定组织好目录结构时。这种方式在本地开发中很常见，你可以将公钥提交到仓库，私钥放在本地忽略的目录。

-k 直接密钥模式 ：

  • 用法 ： ejson decrypt -k /path/to/private_key_file secrets.ejson 或 ejson decrypt -k - secrets.ejson （从标准输入读取密钥）。
  • 机制 ：直接使用指定的文件内容作为私钥，忽略 .ejson 文件中的 _public_key 字段。这意味着，只要这个私钥是当初用于加密的那个密钥对之一，就能解密。它不关心公钥文件名匹配。
  • 适用场景 ：在自动化环境中，私钥通常从秘密管理器动态获取并写入一个临时文件或通过管道传递。此时使用 -k 最为直接。使用 -k - 从标准输入读取尤其安全，可以避免在磁盘上创建临时文件。
# 从环境变量通过管道传递，不落盘
echo "$EJSON_PRIVATE_KEY" | ejson decrypt -k - secrets.ejson > secrets.json

选择建议 ：

  • 自动化流水线/容器 ：优先使用 -k 选项，特别是 -k - ，配合环境变量或秘密管理器的CLI输出。
  • 本地开发/多项目 ：可以使用 --keydir ，将不同项目的公钥收集在一个目录，私钥统一放在本地安全位置（如 ~/.ejson/keys ），并通过 --keydir ~/.ejson/keys 快速解密。

2.6 技巧六：处理多公钥加密与密钥轮转场景

一个 .ejson 文件可以被多个公钥加密。这在团队协作和密钥轮转时非常有用。文件中的 _public_key 字段会变成一个公钥数组。

加密时添加多个公钥 ：

# 假设你有 public_key_1.pub 和 public_key_2.pub
ejson encrypt --keydir ./keys --public-key public_key_1.pub --public-key public_key_2.pub secrets.json -o secrets.ejson

生成的 secrets.ejson 文件，持有 private_key_1 或 private_key_2 中任意一个私钥的人都能解密。

密钥轮转实战 ： 假设你要将旧密钥 old_key 轮转到新密钥 new_key ，同时保证服务不中断。

  1. 用新公钥加密现有数据 ：首先，你需要用 old_key 的私钥解密文件，然后立即用 old_key 和 new_key 的 两个公钥 重新加密。 
    # 解密得到明文
ejson decrypt -k old_private_key secrets.ejson > secrets.json
# 用新旧两个公钥重新加密
ejson encrypt --public-key old_key.pub --public-key new_key.pub secrets.json -o secrets.ejson
  2. 部署与验证 ：部署这个双重加密的文件。此时，使用 old_key 或 new_key 的私钥都能解密，系统正常运行。
  3. 更新客户端配置 ：将你的应用服务器、CI/CD环境等所有需要解密的地方，逐步从使用 old_private_key 切换到使用 new_private_key 。
  4. 移除旧公钥 ：确认所有客户端都已成功切换至新密钥后，再次解密文件，并 仅用 new_key 的公钥 重新加密，完成轮转。 
    ejson decrypt -k new_private_key secrets.ejson > secrets.json
ejson encrypt --public-key new_key.pub secrets.json -o secrets.ejson

注意事项 ：密钥轮转期间，务必确保双重加密的文件安全，并且有完备的回滚计划。在移除旧密钥前，务必确认没有任何关键服务或流程还在依赖它。

2.7 技巧七：调试“解密失败”与版本兼容性问题

有时一切配置看起来都正确，但 ejson decrypt 就是静默失败或输出错误信息。除了检查密钥和权限，还需要考虑以下方面：

1. 验证.ejson文件完整性 ： 首先，检查 .ejson 文件是否是一个有效的JSON文件，并且包含必要的 _public_key 和加密后的数据字段。可以使用 jq . your_file.ejson 来漂亮地打印并验证结构。确保文件没有在传输或编辑过程中被损坏。

2. 确认加密/解密工具版本一致 ： EJSON的加密算法或格式可能在版本间有细微变动。如果你用较新版本的 ejson 命令行工具加密了文件，却尝试用旧版本的工具或客户端库解密，可能会失败。

  • 检查版本 ： ejson --version
  • 解决方案 ：在团队和所有部署环境中 固定EJSON工具的版本 。在Dockerfile中明确指定安装版本，在CI脚本中使用固定版本的二进制包。对于Ruby项目，在Gemfile中锁定 ejson gem的版本；对于Go项目，注意使用的 go-ejson 库版本。

3. 使用详细输出模式 ： ejson 命令通常输出简洁。添加 -v 或 --verbose 标志可以获取更多调试信息，有时能提示是密钥不匹配、文件损坏还是其他内部错误。

ejson decrypt -v -k private_key secrets.ejson

4. 最小化复现 ： 如果问题复杂，尝试创建一个最小化的测试用例：

# 1. 生成一个全新的测试密钥对
ejson keygen test_key
# 2. 创建一个简单的secrets.json
echo '{"password":"supersecret"}' > test.json
# 3. 用测试公钥加密
ejson encrypt --public-key test_key.pub test.json -o test.ejson
# 4. 用测试私钥解密（应该成功）
ejson decrypt -k test_key test.ejson
# 5. 现在用你的问题私钥尝试解密这个test.ejson（应该失败，除非是同一个密钥对）
ejson decrypt -k your_problem_key test.ejson

这个过程能帮你快速隔离问题，确定是特定文件的问题，还是普遍性的密钥/环境问题。

2.8 技巧八：在Docker容器与Kubernetes中无缝集成EJSON

在容器化部署中集成EJSON，核心思想是 在容器启动时或应用启动前完成解密 ，并将解密后的秘密以安全的方式提供给应用进程。

Docker容器内的解密模式：

  1. 构建时解密（不推荐） ：在Dockerfile的构建阶段解密秘密并打包进镜像。这会导致秘密留存在镜像层中，即使后续删除文件，在镜像历史中仍可被提取，存在严重安全风险。 应避免此方法 。
  2. 运行时解密（推荐） ：将加密的 .ejson 文件通过卷挂载或ConfigMap注入容器，将私钥通过环境变量或Kubernetes Secret注入，然后在容器启动脚本（如 entrypoint.sh ）中执行解密。
# Dockerfile 示例
FROM alpine:latest
RUN apk add --no-cache ejson
WORKDIR /app
COPY entrypoint.sh .
COPY --chown=nobody:nobody secrets.ejson . # 假设以nobody用户运行
USER nobody
ENTRYPOINT ["./entrypoint.sh"]

#!/bin/sh
# entrypoint.sh
# 从环境变量获取私钥并解密
if [ -n "$EJSON_PRIVATE_KEY" ]; then
  echo "$EJSON_PRIVATE_KEY" | ejson decrypt -k - secrets.ejson > secrets.json || exit 1
  # 可选：解密后立即清除环境变量，减少内存中暴露时间
  unset EJSON_PRIVATE_KEY
else
  echo "错误：EJSON_PRIVATE_KEY 环境变量未设置" >&2
  exit 1
fi
# 启动主应用，假设应用会读取 secrets.json
exec node server.js

运行容器时： docker run -e EJSON_PRIVATE_KEY="你的私钥" your-image

在Kubernetes中的最佳实践：

  1. 将.ejson文件存入ConfigMap ： 
    kubectl create configmap app-secrets-encrypted --from-file=secrets.ejson
  2. 将私钥存入Secret ： 
    kubectl create secret generic ejson-private-key --from-literal=key='你的私钥内容'
  3. 在Pod中挂载和使用 ： 
    apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: app
    image: your-image
    env:
    - name: EJSON_PRIVATE_KEY
      valueFrom:
        secretKeyRef:
          name: ejson-private-key
          key: key
    volumeMounts:
    - name: encrypted-secrets
      mountPath: /app/secrets.ejson
      subPath: secrets.ejson
      readOnly: true
  volumes:
  - name: encrypted-secrets
    configMap:
      name: app-secrets-encrypted
    这样，容器启动时， entrypoint.sh 脚本就能从环境变量读到私钥，从文件读到加密数据，完成解密。

实操心得 ：在K8s中，也可以考虑使用 Init Container 来负责解密。Init Container拥有私钥，解密后将明文秘密写入一个EmptyDir卷，主容器从该卷读取。这实现了更清晰的职责分离，主容器完全不需要接触私钥。

2.9 技巧九：编写健壮的自动化解密脚本

在CI/CD或运维脚本中，不能假设解密永远成功。必须编写具有错误处理、日志记录和清理功能的健壮脚本。

一个包含完整错误处理的Shell脚本示例： 

#!/bin/bash
set -euo pipefail  # 启用严格错误处理

SECRETS_FILE="config/secrets.ejson"
OUTPUT_FILE="config/secrets.json"
LOG_FILE="/tmp/decrypt_$(date +%Y%m%d_%H%M%S).log"

# 函数：记录日志并错误退出
log_and_die() {
    echo "[ERROR] $(date): $1" | tee -a "$LOG_FILE"
    exit 1
}

# 检查必要文件
if [[ ! -f "$SECRETS_FILE" ]]; then
    log_and_die "加密文件 $SECRETS_FILE 不存在。"
fi

# 检查私钥环境变量
if [[ -z "${EJSON_PRIVATE_KEY:-}" ]]; then
    log_and_die "环境变量 EJSON_PRIVATE_KEY 未设置。"
fi

# 创建临时密钥文件，设置严格权限
TEMP_KEY_FILE=$(mktemp /tmp/ejson_key.XXXXXX)
trap 'rm -f "$TEMP_KEY_FILE"' EXIT INT TERM  # 确保脚本退出时删除临时文件
echo "$EJSON_PRIVATE_KEY" > "$TEMP_KEY_FILE"
chmod 600 "$TEMP_KEY_FILE"

echo "[INFO] $(date): 开始解密 $SECRETS_FILE ..." | tee -a "$LOG_FILE"

# 执行解密，捕获输出和错误
if echo "$EJSON_PRIVATE_KEY" | ejson decrypt -k - "$SECRETS_FILE" > "$OUTPUT_FILE" 2>> "$LOG_FILE"; then
    # 验证输出是否为合法JSON（可选但推荐）
    if jq empty "$OUTPUT_FILE" 2>/dev/null; then
        echo "[SUCCESS] $(date): 解密成功，输出至 $OUTPUT_FILE" | tee -a "$LOG_FILE"
        # 可选：设置输出文件权限
        chmod 640 "$OUTPUT_FILE"
    else
        log_and_die "解密输出不是有效的JSON文件，可能解密失败。"
    fi
else
    log_and_die "解密命令执行失败。请检查 $LOG_FILE 获取详细信息。"
fi

# 安全清理：覆盖并删除临时密钥文件（在trap中已做，此处是二次清理）
shred -u "$TEMP_KEY_FILE" 2>/dev/null || rm -f "$TEMP_KEY_FILE"

echo "[INFO] $(date): 解密流程完成。" | tee -a "$LOG_FILE"

脚本要点解析：

  • set -euo pipefail ：确保脚本在命令失败、变量未定义或管道错误时立即退出。
  • trap ... EXIT ：注册一个退出处理函数，无论脚本因何退出（正常、错误、中断），都会执行 rm -f "$TEMP_KEY_FILE" ，防止临时密钥文件残留。
  • 使用 mktemp 创建安全的临时文件。
  • 解密后使用 jq 验证输出是否为合法JSON，增加一层校验。
  • 详细的日志记录到文件和控制台，便于事后排查。

2.10 技巧十：构建团队内的EJSON使用规范与知识库

最后，也是最重要的技巧，是将这些分散的经验固化为团队的规范和共享知识。个人技巧再高，也抵不过团队协作中的信息差和操作不一致带来的风险。

制定团队规范文档，应包含：

  1. 密钥生成与保管流程 ：明确谁、在何环境、如何生成密钥对。规定公钥存放位置（如 infrastructure/ejson-keys/ 目录），私钥必须存入指定的秘密管理服务（如Vault）。
  2. 加密/解密操作指南 ：提供标准的命令行示例，包括如何添加新秘密、如何用多个公钥加密、如何轮转密钥。
  3. 环境配置清单 ：列出不同环境（开发、测试、预生产、生产）对应的EJSON文件路径、密钥来源（如Vault路径或环境变量名）。
  4. CI/CD集成模板 ：为GitLab CI、GitHub Actions、Jenkins等提供可直接复用的Job/Step模板，确保所有项目解密操作一致。
  5. 故障排查清单 ：就是本文的精华浓缩版，列出如“解密失败第一步做什么”、“如何检查密钥格式”、“常见的权限错误有哪些”等。
  6. 应急预案 ：明确当主私钥泄露或丢失时的应急处理流程，包括如何启用备份密钥、如何重新加密所有秘密、如何通知相关服务负责人。

建立共享知识库： 在团队的Wiki或Notion中创建一个“EJSON实战”页面。除了规范文档，还可以添加：

  • 真实案例记录 ：记录团队历史上遇到过的典型EJSON问题及其解决方案。
  • 脚本库 ：共享像技巧九中那样的健壮解密脚本、密钥轮转脚本等。
  • 新成员上手检查单 ：引导新成员完成从安装EJSON工具到成功解密第一个文件的完整流程。

通过将这些经验制度化、文档化，你能将EJSON从一个潜在的“故障点”，转变为一个可靠、可审计、团队成员都能自信使用的秘密管理基石。这不仅能减少故障，更能提升整个团队的安全意识和运维效率。

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 亚马逊云科技技术品牌专区