这么写是吧？我以为你会给每个业务模块拆出来作为一个 store，你现在还是分的 service 和 system。先这样吧

其实两种都可以,我觉得全拆开会好一点,那就拆开写吧,套一层有种脱裤子放屁的感觉

这么写是吧？我以为你会给每个业务模块拆出来作为一个 store，你现在还是分的 service 和 system。先这样吧

其实两种都可以,我觉得全拆开会好一点,那就拆开写吧,套一层有种脱裤子放屁的感觉

先按你这样写吧，这样改动成本小，风险小。后面碰到具体业务的时候，再把这个业务对应的模块拆出来。

如果一次性拆完的话，所有用户在整个 app 范围内都要丢一次缓存。后面慢慢拆的话，业务模块更新了，一个模块丢缓存用户反馈应该不会太强。

你这次这样拆成两块也会丢缓存，但是粒度比较粗，方便给原来的缓存迁移过来。从 vuex 这个 key 下面拿到缓存，然后把 service 和 system 两个大对象拿出来，写到新的缓存项，然后给 vuex 这条缓存记录删掉。这部分逻辑在 app.use() 之前执行。你看这个缓存移植方案行不？

这么写是吧？我以为你会给每个业务模块拆出来作为一个 store，你现在还是分的 service 和 system。先这样吧

其实两种都可以,我觉得全拆开会好一点,那就拆开写吧,套一层有种脱裤子放屁的感觉

先按你这样写吧，这样改动成本小，风险小。后面碰到具体业务的时候，再把这个业务对应的模块拆出来。

如果一次性拆完的话，所有用户在整个 app 范围内都要丢一次缓存。后面慢慢拆的话，业务模块更新了，一个模块丢缓存用户反馈应该不会太强。

你这次这样拆成两块也会丢缓存，但是粒度比较粗，方便给原来的缓存迁移过来。从 vuex 这个 key 下面拿到缓存，然后把 service 和 system 两个大对象拿出来，写到新的缓存项，然后给 vuex 这条缓存记录删掉。这部分逻辑在 app.use() 之前执行。你看这个缓存移植方案行不？

我觉得没问题

你快点合进来吧，小步快走，别问题都累计在一个 pr 上

CI报错是lint问题,用store.commit的地方太多了,要不先把这个pr合掉

CI报错是lint问题,用store.commit的地方太多了,要不先把这个pr合掉

这不是 lint 问题啊，你把 store 都删了哪里还是 lint 问题，那几个模块逻辑都不正常了。

早知道你这问题了，直接合吧，后面解决