多项目复用 motion-anything 动效组件，核心不是复制动画代码，而是解决三件事：组件源码在哪里统一维护、业务项目通过什么方式引用、每次改动后如何保证各项目拿到一致的版本。先判断项目间协作方式，再选复用策略，比直接复制文件更省后续成本。
若业务项目少且改动不频繁，复制到各项目或使用 Git 子模块即可；若项目多、需要按版本升级，建议把 motion-anything 发布为私有 npm 包；若所有业务都在同一个仓库里开发，用 monorepo 管理最省心。无论哪种方式，都要让组件自身包含样式和类型，避免依赖宿主项目的构建配置。
先按协作方式选复用策略
复用策略没有绝对标准，只能按团队结构和项目数量做取舍。下面这张表列出四种常见做法的适用场景、操作动作和验证方式。
| 方案 | 适用场景 | 操作动作 | 验证方式 | 主要风险 |
|---|---|---|---|---|
| 直接复制源码 | 项目数量少、组件版本周期长 | 拷贝组件源文件到每个项目 src 或 vendor 目录 | 在业务项目里逐个跑一遍动画交互 | 改动后多项目同步易遗漏，版本漂移 |
| Git Submodule | 组件仓库独立，业务项目各自独立 | 在父仓库中 git submodule add 引入组件仓库 | 更新子模块后跑现有动画用例 | 子模块指针更新容易被忽略，新人使用成本高 |
| 私有 npm 包 | 项目多、需要对版本分别升级 | 组件单独仓库维护，构建后发布到私有 registry | 业务项目 lockfile 锁定版本后回归测试 | 需要维护私有源和发布权限 |
| Monorepo | 所有业务项目在同一个仓库中 | 将 motion-anything 作为 workspace 下的一个包 | CI 构建时确认各项目使用 workspace 内版本 | 仓库体积变大，CI 配置和依赖隔离变复杂 |
选择时要看两个关键因素：是否有多套独立发布流程，以及组件版本是否会经常变化。如果业务项目都在独立的 Git 仓库里、版本要求不同，私有 npm 包通常比复制和 Submodule 更可控；如果团队已经习惯 monorepo，那就不需要额外引 npm 源。
私有 npm 包接入步骤（推荐）
私有 npm 包适合大多数“多项目、多版本”的复用场景。先要有一个独立的组件仓库，motion-anything 自身按标准包规范维护。
第一步，在组件仓库里确认构建配置。确保产物包含 ES Module 和类型声明，并把组件内部依赖声明为 peerDependencies。第二步，发布到公司私有 registry。以命令行执行为例：
cd motion-anything
npm run build
npm publish `--registry` https://npm.your-registry.com第三步，在业务项目中安装并指定版本号。建议同时加上私有源参数：
npm install @your-scope/motion-anything@^0.1.0 `--registry` https://npm.your-registry.com如果项目里已有 .npmrc，也可以直接在文件中写 registry 地址，这样团队成员无需每次输入 `--registry`。安装完成后，检查 node_modules 中是否有对应包，并在业务入口引入组件测试。
发布前建议先跑一次构建，确认没有引用组件仓库本地的相对路径。发布后，用一个空白脚手架做一次安装验证，能避免把“构建时正常、安装后缺失”的问题带到业务项目。
版本更新与多项目同步策略
发布到 npm 只是起点，后续维护才影响长期成本。建议采用 semver 语义化版本：修复内部实现用 patch，新增动效或参数用 minor，破坏既有 API 时用 major。每次发布前更新 CHANGELOG，并在业务项目里按依赖组升级，而不是一次性跨多个版本。
如果业务项目数量很多，可以引入 Renovate 这类依赖更新工具，让组件升级变成可控的 PR。每次升级组件版本时，至少要检查：动效导出名是否变化、组件是否需要新的参数、样式选择器是否可能和业务项目冲突、产物是否仍然支持目标浏览器。
日常维护中的关键边界
组件复用的风险点往往不在发布流程，而在“被多个项目共享”后的隐性依赖。比如 motion-anything 如果内部使用全局 CSS 选择器，就可能覆盖业务项目的样式。建议组件根节点使用带前缀的 class 名，样式写在独立文件中，让业务项目可以覆盖。又比如组件如果依赖了 React 或 Vue 的同版本，但业务项目装了不同版本，会产生多实例问题。需要将组件框架声明在 peerDependencies，并提示业务项目安装一致版本。
开发调试时，可以用 npm link 让业务项目直接引用本地源码，但要注意 link 后会跳过 node_modules 依赖解析，可能出现两份 React 实例。更稳妥的做法是在业务项目里加一条 devDependencies 指向本地 tarball，或者直接用 workspace。无论哪种，调试完成后要把引用切回到正式版本。
最后再确认一点：上述所有步骤都需要结合你当前用的包管理器和构建路径来调整。比如 pnpm 的 workspace 和 npm 的 workspace 配置不同，私有 registry 地址也需要拿到公司实际的值。这里给出的是通用执行骨架，替换占位符后再走一遍安装、构建、回归测试。