桌面软件和浏览器扩展：目录站的第三条入口

目录站的价值是"用户想找某个网站的时候会想到你"。这个时刻在浏览器里发生得最多，尤其是新标签页。把入口做成浏览器扩展，逻辑上很通顺。

但扩展和网页不是一回事。它不产生能被搜索引擎索引的页面（扩展里的页面基本不在抓取范围内），它的分发走的是应用商店，它的审核规则是商店定的。用做网站的思路做扩展，容易两头不讨好。

图片来源：网络，版权归原作者所有，侵权请联系删除

入口和落地页是两件事，都得有

扩展本身不会被搜索引擎收录，但它的落地页会。用户搜"XX 导航 扩展""新标签页 导航"这类词时，搜到的是你官网上那个介绍页，不是商店页面。

落地页上该有几样东西，缺一样转化率就会掉一截：

• 这个扩展具体做什么，用三句话说清，配三到五张真实截图（截图要来自实际安装后的界面）
• 申请了哪些权限，每一项对应什么功能，为什么需要
• 更新日志，最近一次更新是什么时候、改了什么
• 隐私说明：收集什么、不收集什么、数据存在哪
• 不支持的情况：比如只支持某些浏览器版本、某些系统上有限制

权限说明那一块很多人糊弄过去，其实它最影响安装率。用户看到"读取和更改你在所有网站上的数据"这种描述，多半直接关掉。所以反过来推：权限申请越少越好，能用 activeTab 解决的不要用 <all_urls>，能不申请 cookies 就不要申请。host_permissions 里能限定域名就别写通配。

新标签页扩展的几条硬规矩

新标签页替换类扩展是商店审核的重点区域。几条必须守住：

覆盖行为要能撤销。用户装完之后要能方便地改回去，设置里给一个明确的开关。

默认搜索引擎、首页这些如果被修改，必须让用户明确选择，不能默认替他改。这条是商店政策的红线区，也是被下架最多的一类原因。

商店页面上的描述、截图要和实际功能一致。功能更新之后商店描述要跟着改，长期不一致会被投诉。

如果扩展会加载远程内容（比如从你的服务器拉导航数据），这个行为要在隐私政策里写清楚，商店审核会看。

桌面软件这条路更重

做桌面客户端的成本比扩展高一个量级：要打包 Windows 和 macOS 两个版本，要处理更新机制，Windows 上还有个绕不开的签名问题。没有代码签名的安装包，Windows 会弹 SmartScreen 警告，用户看到"未知发布者"多数就不装了，而签名证书是要花钱买的。

所以桌面软件适合已经有稳定用户量的目录站，作为增强而不是起点。真要做，下载页上要写清系统要求、安装包大小、有没有捆绑、校验值（哈希）是多少。这几项看着琐碎，缺了就会收到一堆"装不上"的反馈。

更新检查也要想清楚频率。客户端每次启动都去查一次更新，量大了就是给自己加负载；一天查一次足够，而且要能优雅失败，服务器挂了不能让客户端打不开。

别把主站掏空

这是做扩展时最常见的战略失误。为了把扩展做重，把主站的功能一个个搬进去：分类浏览搬进去、搜索搬进去、收藏同步搬进去。最后扩展好用，网页版没人去了，而网页版才是唯一能带来搜索流量的那个。

合理的分工是：扩展负责"最快那一下"，也就是新标签页直接给入口、直接能搜；主站负责全量的浏览、筛选、详情页、分类。数据走同一个接口，两边共用，但功能深度不一样。

接口这层要单独设计，限流、配额、使用条款都要有。扩展是安装在用户机器上的程序，它请求接口的频率你控制不了，一旦被滥用，压力全在你这边。

多端的数据一致性

扩展、网页、小程序如果各调各的数据，很快就会出现"扩展上看到 173 个条目，网页上是 169 个"这种差异。用户不一定会发现，但发现一次就不信任了。做法是只维护一份数据源，各端都从同一个接口取，缓存时间各自定。

条目下架这件事尤其要同步。某个站点因为违规被你下架，扩展的缓存里如果还留着，用户还能点进去，这个责任在你。下架操作要能主动推送清除各端缓存，或者把缓存时间压到足够短。

---

做扩展的价值不在于多一个渠道，而在于占住那个用户每天打开十几次的位置。想清楚这一点，就知道该把什么功能放进去、什么功能留在网页版了。