图片管理系统开发

项目背景

这个项目包含两个代码库：一个用 TypeScript 写的图床（图片托管）服务，一个用 JavaScript 写的浏览器插件，用于在招聘平台上批量上传简历与附件。两个仓库最后一次提交都在 2025 年 8 月。

客户当时的状态

招聘场景的日常动作高度重复：同一个人要在多个平台投递或维护简历，每上传一次附件就要点一遍选文件、等一遍上传。动作本身不难，但一天做几十次就是纯消耗。这类重复动作适合交给工具，问题在于怎么交——直接对目标网站做改动既不可行，也不该那么做；而把简历托管到自己控制的服务上，又会带来存储与访问策略的选择。

我们的做法与取舍

第一个取舍是把文件托管单独做成一个服务，而不是让插件自己存。插件是短生命周期的东西，宿主站点一改版就可能失效，把数据放在插件里等于把数据放在了一个不稳定的载体上。

第二个取舍是用浏览器插件而不是脚本注入。插件是浏览器提供的正规扩展形态，权限边界清楚，安装与卸载由用户控制。代价是每个宿主站点的页面结构都要单独适配。

第三个取舍是如实说明插件类项目的固有风险：插件依赖目标网站的页面结构，对方改版就可能导致上传动作失效，需要跟进维护。这一点在交付时我们就跟客户讲清楚了，没有把它包装成「一次开发永久可用」。

系统怎么承载这条链路

图床服务负责文件的接收、存储与访问地址分发，用 TypeScript 实现，对外提供稳定的文件地址；浏览器插件负责在招聘平台页面上完成批量选取与上传的自动化，把用户的操作次数压下来。两者通过接口衔接——文件先进图床，插件再把地址提交到目标页面，职责不重叠。

交付状态与边界

两个代码库的最后一次提交都在 2025 年 8 月，目前没有新的更新。边界说明：图床服务承载的是文件的存储与访问，不承担内容的合规审查，上传内容的责任在使用方；浏览器插件依赖目标网站的页面结构，目标网站改版可能导致功能失效，这一点在交付时就已书面说明，后续适配属于维护范围；插件不绕过任何平台的账号与权限机制，使用的是用户自己的登录态。