当前位置：首页 > news >正文

GitHub资源列表自动化维护：链接监控与README生成实战

news 2026/7/6 8:56:06

1. 项目概述：当“Awesome”项目遇上维护难题

如果你在GitHub上维护过一个类似“Awesome Web Desktops”这样的列表型项目，你一定深有体会：最头疼的不是收集内容，而是日复一日的维护。这类项目通常汇集了大量第三方链接，比如开源项目、在线演示、技术文章等。今天链接还活蹦乱跳，明天可能就404了；今天项目还叫“A”，明天作者可能就改名成了“B”。手动检查？那简直是维护者的噩梦。更别提每次新增条目后，还要手动去更新README里的分类、描述和格式，确保排版美观、结构清晰。

这个“Awesome Web Desktops项目维护工具揭秘”要解决的，正是这两个核心痛点：链接有效性监控与README文档的自动化生成与更新。它不是某个单一的软件，而是一套基于常见开发工具链组合而成的自动化工作流思路。其核心价值在于，将维护者从繁琐、重复且容易出错的体力劳动中解放出来，让“Awesome”列表能够持续、健康地“活”下去，保持其作为高质量资源索引的可靠性。

简单来说，这套工具能帮你自动完成两件事：第一，定期扫描项目里所有外部链接，告诉你哪些挂了、哪些重定向了、哪些变慢了；第二，当你通过更友好的方式（比如一个简单的YAML文件或数据库）管理资源条目后，它能自动生成格式规范、排版精美的README.md文件。无论是个人维护的小型列表，还是社区协作的大型资源库，这套方法都能显著提升维护效率和项目质量。接下来，我们就深入拆解这套工具链的设计思路、技术选型和实操细节。

2. 核心需求与方案设计解析

在动手搭建任何工具之前，明确需求边界是第一步。对于一个资源列表项目的维护，我们可以将需求拆解为以下几个具体且可衡量的目标：

2.1 链接监控：要监控什么？怎么才算“有效”？

链接监控远不止是检查HTTP状态码是否为200。一个健壮的监控方案需要考虑多种失效场景：

完全失效：返回404（未找到）、403（禁止访问）、500（服务器错误）等状态码。
软失效：返回200，但页面内容已变更，例如项目仓库已迁移（GitHub的Moved Permanently提示）、域名出售停放页面、或内容被替换。
重定向链：链接发生了多次重定向，最终虽然可达，但原始链接已失效，这会影响书签和引用。
性能问题：响应时间极长（如超过10秒），虽然没“死”，但用户体验极差，对于在线演示类链接尤其重要。
内容匹配：对于特定资源（如一个Web Desktop的在线Demo），我们可能希望页面上存在某些关键词（如“Desktop”、“Demo”、“React”）来确认链接内容未偏离主题。

因此，我们的监控工具需要能配置多维度检查策略，而不仅仅是简单的HTTP GET请求。

2.2 README生成：源数据如何管理？模板如何设计？

手动维护README的弊端很明显：格式不一致、容易遗漏更新、协作冲突。自动化生成README的前提是将内容（数据）与表现形式（视图）分离。

数据源：我们需要一个结构化的数据源来存储所有资源条目。常见的选择有：
- YAML/JSON文件：易于阅读和手动编辑，适合中小型项目。每个条目可以包含name、url、description、tags、star等字段。
- 轻量级数据库（如SQLite）：适合条目众多、需要复杂查询和关联的项目。
- 前端Matter：在Markdown文件顶部用YAML存储元数据，但管理大量条目时不如独立数据文件方便。
模板引擎：我们需要一个工具，能够根据定义好的模板，将结构化的数据渲染成最终的Markdown文本。模板中需要支持循环（遍历所有条目）、条件判断（按分类显示）、变量插值（插入条目信息）等功能。
输出与格式化：生成的README不仅要内容正确，排版也要美观，包括正确的标题层级、列表、代码块、表格等Markdown语法，以及符合项目风格的徽章（Badges）。

2.3 方案选型：为什么是这些工具？

基于以上需求，一个典型的技术选型组合如下：

链接监控：Node.js+axios+cheerio。Node.js生态丰富，axios用于发送HTTP请求并处理重定向、超时，cheerio可以像jQuery一样解析HTML，用于内容匹配检查。Python的requests+BeautifulSoup组合也是极佳选择，视团队技术栈而定。
任务调度与自动化：GitHub Actions。它是托管在GitHub上的CI/CD服务，完美契合GitHub项目。可以定时（如每天凌晨）触发监控任务，并将结果通过Issue、Pull Request或Commit直接反馈到仓库中。
README生成：JavaScript/Node.js+模板字符串或EJS/Handlebars等模板引擎。如果数据结构简单，用JavaScript的模板字符串拼接即可；如果模板复杂，使用专门的模板引擎更清晰。另一种流行选择是使用Python的Jinja2模板引擎，功能强大。
数据源：选择YAML文件。因为它对人类友好（方便手动微调），对机器也友好（有成熟的解析库），是开源项目中最常见的选择。

这个组合的优势在于低成本、高集成度和可扩展性。所有工具都是开源、免费的，并且能无缝融入GitHub的工作流。监控脚本发现问题可以自动创建Issue提醒，生成README后可以自动提交更新，实现了“无人值守”的自动化维护。

3. 实操构建：链接健康监控系统

让我们从最紧迫的链接监控开始。我们将构建一个Node.js脚本，它读取一个包含所有链接的数据文件，进行检查，并生成一份报告。

3.1 环境准备与项目结构

首先，在你的项目根目录下，初始化一个Node.js环境并安装依赖。

# 初始化项目（如果已有package.json可跳过） npm init -y # 安装核心依赖 npm install axios cheerio yaml js-yaml

axios：用于发送HTTP请求，支持Promise、拦截器、超时设置，比原生http模块更友好。
cheerio：服务器端的jQuery实现，用于解析和操作HTML。
yaml/js-yaml：用于解析和加载YAML格式的数据源文件。

一个清晰的项目结构有助于管理：

your-awesome-repo/ ├── .github/ │ └── workflows/ │ └── link-checker.yml # GitHub Actions 工作流定义 ├── scripts/ │ ├── link-checker.js # 链接检查主脚本 │ └── generate-readme.js # README生成脚本 ├── data/ │ └── resources.yaml # 结构化的资源数据源 ├── README.md # 将由脚本自动生成 └── package.json

3.2 设计结构化数据源 (resources.yaml)

这是整个自动化系统的“单一数据源”。所有操作都基于这个文件。

categories: - name: "Vue.js Based" description: "使用Vue.js框架构建的Web桌面环境。" resources: - name: "Vue Desktop" url: "https://github.com/taylorchen709/vue-desktop" homepage: "https://vue-desktop.github.io/" # 可选：演示地址 description: "一个基于Vue.js的轻量级Web桌面模拟器。" tags: ["vue", "desktop", "simulator"] star: 1200 - name: "React Based" description: "使用React框架构建的Web桌面环境。" resources: - name: "React Desktop" url: "https://github.com/gabrielbull/react-desktop" description: "一个使用React构建的跨平台桌面UI库。" tags: ["react", "ui-library", "windows"] star: 9800

这个结构定义了分类和资源，包含了名称、URL、描述、标签等关键信息。homepage和star是可选项，用于更丰富的展示。

3.3 编写链接检查脚本 (link-checker.js)

这个脚本的核心逻辑是：加载YAML数据 -> 提取所有URL -> 并发检查 -> 输出报告。

const fs = require('fs'); const yaml = require('js-yaml'); const axios = require('axios'); const cheerio = require('cheerio'); // 1. 加载数据 const data = yaml.load(fs.readFileSync('./data/resources.yaml', 'utf8')); // 2. 提取所有需要检查的URL（包括项目地址和主页） const urlsToCheck = []; data.categories.forEach(cat => { cat.resources.forEach(res => { urlsToCheck.push({ type: 'repo', url: res.url, name: res.name }); if (res.homepage) { urlsToCheck.push({ type: 'homepage', url: res.homepage, name: res.name }); } }); }); // 3. 检查函数 async function checkLink(linkObj) { const { url, name, type } = linkObj; const result = { url, name, type, status: 'unknown', error: null, statusCode: null, finalUrl: url, loadTime: null }; try { const startTime = Date.now(); // 设置请求配置：超时10秒，跟随重定向，并记录最终URL const response = await axios.get(url, { timeout: 10000, maxRedirects: 5, validateStatus: function (status) { // 认为所有状态码都是有效的，这样我们才能获取到非200的响应信息 return true; } }); const endTime = Date.now(); result.statusCode = response.status; result.finalUrl = response.request.res.responseUrl || url; // 获取重定向后的最终URL result.loadTime = endTime - startTime; // 判断逻辑 if (response.status === 200) { // 对于主页，可以进行简单的内容验证 if (type === 'homepage') { const $ = cheerio.load(response.data); const pageText = $('body').text().toLowerCase(); // 示例：检查页面是否包含某些关键词（可根据项目调整） if (pageText.includes('desktop') || pageText.includes('demo')) { result.status = 'healthy'; } else { result.status = 'content_mismatch'; // 内容可能不相关 } } else { result.status = 'healthy'; } } else if (response.status === 404 || response.status === 410) { result.status = 'broken'; } else if (response.status >= 300 && response.status < 400) { result.status = 'redirected'; } else { result.status = 'error'; // 其他4xx, 5xx错误 } } catch (error) { result.status = 'error'; result.error = error.code || error.message; // 网络超时、DNS错误等都会在这里捕获 } return result; } // 4. 并发检查（控制并发数，避免对目标服务器造成压力） async function checkAllLinks(urls, concurrency = 5) { const results = []; for (let i = 0; i < urls.length; i += concurrency) { const batch = urls.slice(i, i + concurrency); const batchResults = await Promise.all(batch.map(checkLink)); results.push(...batchResults); // 可选：每检查完一批，等待一小段时间，以示友好 await new Promise(resolve => setTimeout(resolve, 500)); } return results; } // 5. 主执行函数 (async () => { console.log(`开始检查 ${urlsToCheck.length} 个链接...`); const results = await checkAllLinks(urlsToCheck); // 6. 分析与报告生成 const brokenLinks = results.filter(r => r.status === 'broken'); const redirectedLinks = results.filter(r => r.status === 'redirected'); const errorLinks = results.filter(r => r.status === 'error'); const mismatchLinks = results.filter(r => r.status === 'content_mismatch'); console.log('\n======= 链接健康检查报告 ======='); console.log(`总计: ${results.length}`); console.log(`健康: ${results.filter(r => r.status === 'healthy').length}`); console.log(`失效: ${brokenLinks.length}`); console.log(`重定向: ${redirectedLinks.length}`); console.log(`错误: ${errorLinks.length}`); console.log(`内容不匹配: ${mismatchLinks.length}`); // 输出有问题的链接详情 if (brokenLinks.length > 0) { console.log('\n❌ 失效链接:'); brokenLinks.forEach(link => { console.log(` - ${link.name} (${link.type}): ${link.url} -> ${link.statusCode}`); }); } if (redirectedLinks.length > 0) { console.log('\n⚠️ 重定向链接 (请考虑更新为最终地址):'); redirectedLinks.forEach(link => { console.log(` - ${link.name} (${link.type}): ${link.url} -> ${link.finalUrl}`); }); } // 7. 将报告写入文件，供后续GitHub Actions使用 const report = { generatedAt: new Date().toISOString(), summary: { total: results.length, healthy: results.filter(r => r.status === 'healthy').length, broken: brokenLinks.length, redirected: redirectedLinks.length, error: errorLinks.length, mismatch: mismatchLinks.length }, details: { broken: brokenLinks, redirected: redirectedLinks, error: errorLinks, mismatch: mismatchLinks } }; fs.writeFileSync('./link-check-report.json', JSON.stringify(report, null, 2)); console.log('\n详细报告已保存至 link-check-report.json'); })();

注意：此脚本包含了基础的礼貌性等待（setTimeout）和并发控制，但在检查大量外部链接时，仍需谨慎。过于频繁的请求可能触发目标网站的防护机制。建议将concurrency设置为一个较低的值（如3-5），并在GitHub Actions中安排在低峰时段（如UTC时间凌晨）运行。

4. 实操构建：README自动化生成引擎

解决了链接监控，我们再来打造README的自动生成器。目标是：data/resources.yaml一有更新，运行脚本，一个格式统一、信息完整的README.md就诞生了。

4.1 设计README模板

我们可以在脚本中直接使用模板字符串，但为了更清晰，我们将模板逻辑分离。这里我们使用Node.js的模板字符串功能，它足够应对大多数情况。

脚本generate-readme.js的核心思路是：读取YAML数据 -> 按照模板拼接Markdown字符串 -> 写入README.md文件。

一个增强版的生成器可能包含以下部分：

const fs = require('fs'); const yaml = require('js-yaml'); const data = yaml.load(fs.readFileSync('./data/resources.yaml', 'utf8')); // 1. 生成项目徽章（可选，动态生成） const badges = ` [![Link Check](https://github.com/YOUR_USERNAME/YOUR_REPO/actions/workflows/link-checker.yml/badge.svg)](https://github.com/YOUR_USERNAME/YOUR_REPO/actions/workflows/link-checker.yml) [![Awesome](https://awesome.re/badge.svg)](https://awesome.re) `.trim(); // 2. 生成目录 (TOC) let toc = `## 目录\n`; data.categories.forEach((cat, index) => { // 为每个分类生成锚点链接 const anchor = cat.name.toLowerCase().replace(/[^\w]+/g, '-'); toc += `${index + 1}. [${cat.name}](#${anchor})\n`; }); // 3. 生成主体内容 let mainContent = ''; data.categories.forEach(cat => { const anchor = cat.name.toLowerCase().replace(/[^\w]+/g, '-'); mainContent += `## ${cat.name}\n\n`; mainContent += `> ${cat.description}\n\n`; // 使用表格呈现资源，信息更密集、美观 mainContent += `| 项目名称 | 描述 | 技术栈 | 星标 | 演示/主页 |\n`; mainContent += `| :--- | :--- | :--- | :--- | :--- |\n`; cat.resources.forEach(res => { const tags = res.tags.map(t => `\`${t}\``).join(' '); const starBadge = res.star ? `![GitHub Repo stars](https://img.shields.io/github/stars/${res.url.split('github.com/')[1]}?style=social)` : ''; const homepageLink = res.homepage ? `[🔗](${res.homepage})` : ''; // 注意：从GitHub URL中提取 owner/repo 来生成星星徽章 const repoPath = res.url.includes('github.com') ? res.url.split('github.com/')[1] : ''; const starBadgeDynamic = repoPath ? `![GitHub Repo stars](https://img.shields.io/github/stars/${repoPath}?style=flat-square)` : ''; mainContent += `| [**${res.name}**](${res.url}) | ${res.description} | ${tags} | ${starBadgeDynamic} | ${homepageLink} |\n`; }); mainContent += `\n`; }); // 4. 拼接完整的README const fullReadme = `# Awesome Web Desktops 一个精心策划的、关于Web桌面环境（Web Desktop）的优秀项目、库和资源列表。 ${badges} ## 简介 这是一个致力于收集和展示各种在浏览器中实现的桌面环境模拟器的列表。从复古的仿真到现代的生产力套件，这里应有尽有。列表通过自动化工具维护，确保链接有效、信息最新。 ${toc} ${mainContent} ## 贡献 欢迎贡献！请直接编辑 \`data/resources.yaml\` 文件并提交Pull Request。在添加新条目时，请确保其符合“Web桌面环境”的主题，并提供准确的描述和链接。 ## 维护 本项目使用自动化工具进行维护： - **链接监控**: 每日自动检查列表中所有链接的健康状况。 - **README生成**: README.md文件由 \`data/resources.yaml\` 自动生成。 ## 许可 [![CC0](http://mirrors.creativecommons.org/presskit/buttons/88x31/svg/cc-zero.svg)](https://creativecommons.org/publicdomain/zero/1.0/) 本项目采用 [CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/) 许可协议。 `; // 5. 写入文件 fs.writeFileSync('./README.md', fullReadme); console.log('README.md 已成功生成！');

这个脚本生成了一个包含动态徽章、表格化列表、完整目录的README。表格形式能更紧凑地展示更多信息（如技术栈标签、星标数），视觉上也更专业。

4.2 集成与自动化：GitHub Actions工作流

最后，我们将上述两个脚本和潜在的数据更新流程，通过GitHub Actions串联起来，实现完全自动化。

创建.github/workflows/maintain.yml：

name: Maintain Awesome List on: schedule: # 每天UTC时间0点（北京时间早上8点）运行链接检查 - cron: '0 0 * * *' push: # 当 data/resources.yaml 文件被更改时，触发README重新生成和链接检查 paths: - 'data/resources.yaml' branches: [ main, master ] pull_request: # 在PR中修改了数据文件，也进行检查和预览生成 paths: - 'data/resources.yaml' # 也可以手动触发工作流 workflow_dispatch: jobs: check-links: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' - name: Install dependencies run: npm ci # 使用ci命令确保依赖锁一致 - name: Run link checker run: node ./scripts/link-checker.js - name: Upload link check report uses: actions/upload-artifact@v4 if: always() # 即使检查出错也上传报告 with: name: link-check-report path: link-check-report.json - name: Create Issue for broken links if: github.event_name == 'schedule' && failure() # 仅在定时任务且发现失效链接时创建Issue uses: actions/github-script@v7 with: script: | const report = require('./link-check-report.json'); if (report.summary.broken > 0) { const brokenList = report.details.broken.map(l => `- **${l.name}** (${l.type}): ${l.url} (Status: ${l.statusCode})`).join('\n'); await github.rest.issues.create({ owner: context.repo.owner, repo: context.repo.repo, title: `🚨 链接检查发现 ${report.summary.broken} 个失效链接`, body: `在 ${report.generatedAt} 的自动检查中，发现以下链接可能已失效：\n\n${brokenList}\n\n请及时核查并更新。`, labels: ['bug', 'automated-maintenance'] }); } generate-readme: runs-on: ubuntu-latest needs: check-links # 确保在链接检查之后运行（可选） if: github.event_name == 'push' || github.event_name == 'pull_request' || github.event_name == 'workflow_dispatch' steps: - uses: actions/checkout@v4 with: # 对于PR，需要获取完整的提交历史以正确运行 fetch-depth: 0 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' - name: Install dependencies run: npm ci - name: Generate README run: node ./scripts/generate-readme.js - name: Check for README changes id: diff run: | git diff --quiet README.md || echo "has_changes=true" >> $GITHUB_OUTPUT - name: Commit and push README changes (on main branch) if: steps.diff.outputs.has_changes == 'true' && github.event_name == 'push' && github.ref == 'refs/heads/main' run: | git config --local user.email "action@github.com" git config --local user.name "GitHub Action" git add README.md git commit -m "docs: auto-generate README from data/resources.yaml" git push env: # 使用具有写入权限的token GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - name: Output preview in PR if: github.event_name == 'pull_request' run: | echo "### 📄 预览生成的 README" >> $GITHUB_STEP_SUMMARY echo '```markdown' >> $GITHUB_STEP_SUMMARY cat README.md >> $GITHUB_STEP_SUMMARY echo '```' >> $GITHUB_STEP_SUMMARY

这个工作流定义了两个任务（jobs）：

check-links：每天定时运行，并当resources.yaml文件被修改时触发。它运行检查脚本，生成报告，如果发现失效链接（在定时任务中），会自动创建一个GitHub Issue来提醒维护者。
generate-readme：当resources.yaml被修改（通过push或PR）时触发。它重新生成README，如果是在主分支的push事件中，且README有变化，则自动提交更新。如果是在PR中，则会在PR的检查详情中输出生成的README预览，方便贡献者核对。

5. 避坑指南与进阶技巧

在实际部署和运行这套自动化维护工具时，你可能会遇到一些预料之外的问题。以下是我在多个类似项目中总结出的经验教训和进阶建议。

5.1 链接检查的“礼貌性”与稳定性

问题：请求被屏蔽或触发速率限制。你的脚本可能被目标网站视为爬虫。
- 解决方案：
  1. 降低并发度：将并发请求数（concurrency）设置为3或更低。
  2. 增加延迟：在每批请求之间增加更长的延迟（如1-2秒）。
  3. 设置合理的超时：axios的timeout设置为10-15秒，避免长时间挂起。
  4. 使用User-Agent：在请求头中设置一个真实的浏览器User-Agent，例如：axios.get(url, { headers: { 'User-Agent': 'Mozilla/5.0 (Awesome-List-Link-Checker/1.0)' } })。
  5. 尊重robots.txt：对于大型、正式的检查，可以考虑解析目标网站的robots.txt，但对于资源列表项目，通常检查的域名非常分散，此条优先级较低。
问题：误判“软失效”。页面返回200，但内容已完全无关。
- 解决方案：如脚本所示，使用cheerio进行简单的内容验证。你可以定义一个针对不同类型链接的关键词列表。例如，对于“Web Desktop”项目，可以检查页面是否包含“desktop”、“simulator”、“workspace”、“browser-based”等关键词。这能有效过滤掉域名出售页或泛解析的默认页。

5.2 README生成的灵活性与兼容性

问题：数据源格式变更导致脚本出错。

解决方案：在脚本开头对YAML数据进行结构验证。可以使用Joi或ajv等库定义数据模式（Schema），确保必填字段存在、字段类型正确。这能在合并PR前提前发现数据格式错误。

// 示例：使用Joi进行简单验证 const Joi = require('joi'); const categorySchema = Joi.object({ name: Joi.string().required(), description: Joi.string().required(), resources: Joi.array().items(Joi.object({ name: Joi.string().required(), url: Joi.string().uri().required(), description: Joi.string().required(), tags: Joi.array().items(Joi.string()).optional(), star: Joi.number().optional(), homepage: Joi.string().uri().optional() })).required() });

问题：生成的Markdown表格在部分渲染器（如某些编辑器或旧平台）上错乱。
- 解决方案：确保表格的每一行单元格数量一致。在拼接字符串时格外小心。可以使用专门的Markdown表格生成库，如markdown-table，来避免格式错误。

5.3 GitHub Actions的优化与成本

问题：工作流运行时间过长，消耗Actions分钟数。
- 解决方案：
  1. 缓存依赖：使用actions/cache缓存Node.js的node_modules目录，可以大幅缩短安装依赖的时间。
  2. 分离工作流：将高频率的链接检查（每日）和低频率的README生成（仅在数据变更时）彻底分离成两个独立的.yml文件。链接检查可以配置为只在schedule和workflow_dispatch时触发，不响应push事件，除非是推送到数据文件。
  3. 优化检查范围：在push事件触发检查时，可以使用paths-filter动作，仅当data/resources.yaml文件被修改时才运行检查任务，避免无关提交触发工作流。
问题：自动提交（Commit）导致无限循环。
- 解决方案：我们的工作流中，generate-readme任务在提交时使用了if: github.event_name == 'push'来限制。但更安全的做法是，在提交信息中加入特定标识（如[bot]或[skip ci]），并在工作流触发条件中排除包含该标识的提交，防止Actions自己触发自己。不过，GitHub Actions默认会忽略由GITHUB_TOKEN触发的后续工作流，所以示例中的配置在大多数情况下是安全的。

5.4 扩展思路：让列表更“智能”

基础功能实现后，你可以考虑以下增强功能：

自动获取星标数：利用GitHub API，在生成README时动态获取每个仓库的最新star数量，而不是在YAML中写死。这需要处理API速率限制，并可能需要在Actions中配置个人访问令牌（PAT）。
项目健康度评分：结合链接检查结果、GitHub仓库的最近提交时间、issue关闭率等信息，为每个项目计算一个简单的“健康度”分数，并在README中通过徽章或排序体现。
多语言支持：如果你的Awesome列表面向国际社区，可以设计多语言数据结构和模板，根据访问者的语言偏好生成不同版本的README（这需要更复杂的前端支持，但思路可以延伸）。
Web界面管理：为不熟悉YAML和Git的贡献者提供一个简单的Web表单，提交后通过GitHub API或Serverless Function自动创建包含数据更新的PR。

这套工具链的核心思想是“基础设施即代码”和“自动化一切可自动化的”。它将维护一个高质量资源列表的重复性劳动，转化为维护一份高质量的结构化数据（YAML文件）和一套可靠的自动化脚本。一旦搭建完成，你只需关心内容的增删改，剩下的脏活累活，就交给机器在后台默默完成吧。这不仅提升了项目的可靠性和专业性，也让作为维护者的你，能把宝贵的时间投入到更值得的地方——发现和筛选更棒的资源。

查看全文

http://www.jsqmd.com/news/1133738/