Show HN：我抓取了 2500 万个 Shopify 产品来构建一个搜索引擎
一个副业项目从大约 65 万家 Shopify 商店中抓取了 2500 万个产品，以构建一个独立的产品搜索引擎，这引发了技术上的好奇，也带来了对其长期可行性的怀疑。评论者拆解了作者如何获取商店列表、利用公开的 JSON 端点，以及为何选择基于 MongoDB 的高成本技术栈，同时建议使用 Elasticsearch、Typesense、Meilisearch 或 Postgres 等更便宜、更快的替代方案来实现扩展性和更好的相关性。许多人还质疑该产品与 Shopify 自家的 Shop 应用和 Amazon 的差异化，认为成功与否将更多取决于搜索质量、内容整理、欺诈过滤，以及面向消费者和商家的清晰价值主张，而不是抓取规模。
抓取方法与数据来源
- Shopify 商店暴露了标准化的 JSON 端点（
/products.json、/meta.json），因此抓取主要意味着下载这些内容，而不是 HTML。 - 几位评论者指出，你可以几乎不受限地“猛轰”
/products.json，传统的反爬问题（CAPTCHA、IP 封禁）在这里几乎不存在。 - 最初的商店列表来自一个付费的 “BuiltWith” 数据集（约 200 万家商店），然后按地理位置和收入进行了筛选；其他人提到 DNS 模式、
products.json存在与否，或 Shopify 特定的 URL 结构，作为检测方法。 - 有人讨论了 robots.txt 和站点地图作为额外的发现机制，但也有人质疑把“不要抓取”的提示用作种子数据的做法。
技术栈、成本与性能
- 当前技术栈：JavaScript 爬虫、MongoDB Atlas（包括 Atlas Search）、Next.js 前端、AWS 基础设施；成本约为每月 2200 美元。
- 许多人认为，针对约 2500 万个产品，这套方案过于重型，并建议更便宜、更合适的选项：Elasticsearch/OpenSearch、Typesense、Meilisearch、Postgres（带全文检索和向量），甚至单台裸机/Hetzner 服务器。
- 几位评论指出，2500 万文档对现代搜索基础设施来说并不算多，只要架构得当，就应该又快又便宜。
搜索质量与功能
- 用户发现像“red shoes”这样的通用查询结果很弱或很嘈杂；品牌匹配有时会排在明显更符合意图的结果之前。
- 建议包括：使用 CLIP 或类似方案进行向量/语义搜索、稠密图像描述、颜色检测，以及多模态嵌入来提升相关性。
- 期望的筛选项包括：价格、“发往”/“发货自”位置、可用性、NSFW 过滤、配送国家、相似搜索，以及展示同一产品的替代商品。
数据质量、整理与欺诈
- 多条评论警告说，低质量、欺诈或代发货的 Shopify 商店尾部很长。
- 以往项目报告称，需要大量人工和自动化整理来移除垃圾内容、骗局以及敏感/NSFW 内容；许多人认为整理是差异化的关键。
变现、竞争与可行性
- 目前的模式是向“已验证”与置顶列表的商家收取费用；尚无联盟营销收入。
- 几位评论者指出，Shopify 自家的 Shop 应用以及各种比价引擎，既是直接竞争者，也可能是间接竞争者。
- 过往类似项目的经验是：技术实现本身问题不大；真正的瓶颈在于用户获取和变现。
UX 与其他
- 反馈指出响应缓慢、缺少加载指示器、无限滚动问题、导航怪异、Unicode 查询错误，以及希望能方便地“在新标签页打开”。
- 有人质疑 Shopify 的 ToS 影响；也有人不以为意，或认为只有在采取法律行动时才重要。