哪些插件可以用 Shopify 原生功能替代

插件能做的事里，有一批主题和后台本来就能做。判断能不能替代，标准只有一条：原生做法能否覆盖你现在真正用到的功能，并且替换后不需要额外维护。功能够用就换，不够用就别为了省订阅费把需求砍掉。

下面按功能分类列替代关系，再给替换前的检查项。平台的原生能力随套餐与版本变化，具体某个选项在你后台有没有，以后台实际显示为准。

先看原生已经提供了什么

功能	原生做法	替代前要确认
内容区块与版式	Section 与 block：可复用的模块，商家在主题编辑器里增删、排序区块；JSON 模板与 section group 最多渲染 25 个 section，每个 section 最多 50 个 block，并支持应用区块	你的版式复杂度是否超出这个范围
页面类型模板	模板决定每种页面渲染什么，同一类型可以有多套模板，例如为不同品类的产品各做一套；JSON 模板总量有上限	被替换的应用是否生成了独立页面和独立地址
导航与菜单	在后台的菜单页维护链接，显示位置在主题设置里选	应用生成的导航是不是只是链接集合
规格、材质、常见问题、下载资料	用元字段给产品加自定义字段，主题兼容时可在主题编辑器里连接输出	现有内容存在应用的数据库里还是产品数据里
Logo、图标与图片展示	平台上上传的图片、自定义 logo 与 favicon	应用提供的除了展示还有什么独有能力
多语言与多币种基础能力	Markets：按位置、客户组、零售地点、销售渠道定义市场，用定制覆盖货币、语言、价格与主题内容；折扣与礼品卡跨市场可用，固定金额在结账时按币种换算	目标语言有没有可编辑的翻译内容

这几项的官方说明都在对应文档里，可以逐项核对能力边界：主题 Section 说明、模板说明、菜单与链接、产品信息、店铺图片、Markets。

规格表和常见问题这类内容最适合走元字段。字段建好之后要在模板里输出，内容才会出现在可抓取的 HTML 里，只存在后台等于没写，渲染方式可以照着用元字段做内容展示里的做法做，字段命名与输出逻辑的取舍另有一篇元字段对 SEO 的作用可以参考。

可访问性这类问题，插件替代不了主题层的工作

键盘能不能走完从浏览到加购的流程、焦点是否可见、报错信息是否可读，这些取决于主题本身怎么写。官方的主题可访问性最佳实践说明了检查方向，也提醒只按最佳实践做并不保证主题完全可访问。装一个可访问性插件通常解决不了结构层次和焦点管理的问题，具体检查项可以按主题可访问性实操检查走一遍。

评论与评分属于替代不了的一类

产品评论、站内搜索增强、订阅、复杂促销这些能力原生覆盖不了，该用应用还是得用。区别在于要看清它输出的结构化数据：Google 的产品结构化数据说明里列了评分、评价、运费、库存等可以标注的信息，这些信息要和页面上真实可见的内容一致，评分必须有真实来源。展示与否由搜索引擎决定，标注齐了不代表一定会出现富媒体结果。这类应用卸载或替换时，页面上原本由它输出的评分标注会一起消失，替换前要确认新方案能不能接上。

先替换哪一类

不值得按订阅费高低排顺序，容易替换、影响面又大的先做。这类应用有三个特征：只做展示，不参与交易判断；只在特定页面出现，不侵入全站；内容本身可以导出成表格。只做展示的图文块、图标注、规格表、配送说明、常见问题，基本都落在这个范围里。

反过来，涉及价格计算、折扣叠加、库存判断、结账流程的应用不要轻易替换。这些地方出错影响的是收入和订单，而且往往是事后才发现。看着功能简单、实际连着交易逻辑，是这类应用的共同特点。

内容怎么搬到原生做法上

搬运的落点大体三类。结构化的字段进元字段，比如材质、尺寸、功率这类可以逐项列出的信息；版式类的内容进区块，比如场景说明、图文并排的推荐位；政策与说明类的内容进独立页面，从页脚或导航进入。选哪一类，取决于这段内容以后由谁来维护、多久改一次。

元字段要落到模板里才会被输出。下面这段是产品模板里最常见的最小写法，注意判断缺失值，避免没有填写的产品上出现一个空标题：

{% if product.metafields.specs.material != blank %}
  <h3>材质</h3>
  <p>{{ product.metafields.specs.material.value }}</p>
{% endif %}

这段代码放在产品模板或产品相关的 section 里，命名空间与字段名要和后台建的字段一致。字段名不统一是后续维护的主要麻烦来源，命名规则最好在建字段之前就定下来。

多语言与多币种的基础能力够用到哪里

Markets 能按市场给出不同的语言、货币与主题内容，这部分是平台能力，不需要应用也能配。它解决的是展示层的差异，翻译内容本身仍然要你逐条维护：机器翻译能快速覆盖数量，表达是否像本地店铺写的，取决于有没有人回头改。内容质量决定这批页面有没有访问价值，这一点在语言数量多的时候尤其明显。

替换前必须过一遍的检查项

• 数据归属：现在的内容存在应用的数据库里，还是存在产品数据与元字段里。存在应用里的，替换前先导出，能导成表格最好。
• 地址与索引：应用生成过独立地址的，替换后这些地址会失效，需要重定向到新的落点，别让它们直接 404。
• 结构化数据与元信息：应用注入的标注、页面标题与描述模板，是否随卸载一起消失，替代后由谁输出。
• 主题残留：卸载后搜索主题里的应用标识、脚本域名与区块设置，确认没有引用残留，方法见卸载插件后的残留清理。
• 设置依赖：原生做法往往依赖主题设置，换主题时这些配置可能丢失，需要记录成清单。

替换动作不要和促销、主题改版安排在同一个时间窗。同一个时间段里改的东西越多，出问题时就越是分不清是哪一步引起的，而替换本身通常不紧急，等一个流量平稳的时段做，代价更低。

替代算不算成功，看这几项

替换完成后，验收标准和上线新功能不一样，重点在"没有丢东西"。内容层面，替换前存在的规格、说明、常见问题是否都还在页面上，字段缺失的产品有没有出现空标题；结构层面，页面层级与内链是否和原来一致，导航里指向这些内容的入口还能不能用；地址层面，被替换掉的应用生成过的地址有没有落点，直接访问会不会 404。

还有一个可以量化的对比：卸载应用之后，同一个页面的第三方请求数量与页面元素数量应该回到替换前的基线附近。如果卸载已经完成，请求却没有减少，说明还有残留的脚本在加载，这时候要回到主题里把那一段找出来。

一个不容易出错的替换顺序

1. 列出现在装着的应用，每个写清解决什么功能、你实际用到的程度。
2. 标出候选替代，逐个核对上表第三列要确认的事项，先把不确定的排除掉。
3. 在副本主题里做替代实现，原应用先不动，两套并存跑一段时间。挑选应用的思路可以参考选插件看什么。
4. 导出旧数据，同时保存替换前的页面源码片段，作为对比依据。
5. 替换上线后检查页面结构、交互与内链，确认抓取入口没有断。这些页面后续会不会被抓取、被索引，取决于页面本身和搜索引擎的判断，我们通常在做谷歌 SEO 的常规核对时一起看。
6. 观察一段时间再卸载应用，卸载动作和替换动作分开做，出问题时才知道是谁引起的。

边界

• 不同套餐的原生能力不同，多市场、多语言这类功能的可用范围尤其如此，以后台实际能打开的选项为准。
• 深度需求替换不了。订阅计费、复杂促销组合、多仓发货、精细筛选逻辑，几个区块拼不出来，硬拼的结果是维护成本更高。
• 平台会调整设置位置与命名，照着旧版教程操作找不到入口是常态，这类情况以当前后台为准。
• 替代不承诺性能或排名上的改善。原生方案通常更轻，但最终数据要以你自己店铺改动前后的同条件对比为准。
• 应用还在订阅期内的，替换完成后走一遍真实下单流程，确认订单、通知邮件、库存扣减都正常，再去停订阅。
• 替换只是把内容换个地方放，内容本身的表达没有变。要改善这些页面的搜索表现，最终还是要回到内容质量上，这一步没有捷径。

顺着这张表过一遍，多数店铺能砍掉几个低频应用，省下的不只是订阅费，还有每次排查问题时少看一段来历不明的代码。砍不掉的，就是真正需要的。