Bytebase 统一实例许可Unified Instance License实现指南从后端判定到前端呈现的全链路落地【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase本文以 docs/superpowers/plans/2026-04-28-unified-instance-license.md 为骨架讲解 Bytebase 如何把注册实例数 ≤ 激活实例数的许可License统一表现为一个数字的实例许可模式后端只需一个集中式判定助手即可计算有效激活、不必改动存储中的实例元数据前端订阅 Store 同步镜像同一规则让功能开关与设置页在统一模式下隐藏分配assignment类 UI同时保留旧式拆分额度split-cap许可的既有行为。读完本文你将掌握这套方案的统一判定规则、Go 后端落地步骤、Connect v1 API 输出层改造、Pinia 订阅 Store 派生逻辑以及前后端回归测试的完整验证命令。1. 方案背景为什么要引入统一实例许可Bytebase 的实例许可Instance License历史上采用双额度模型一张许可同时携带**注册实例数Instances与激活实例数ActiveInstances**两个上限。注册额度决定工作区能接入多少实例激活额度决定其中有多少实例能启用数据脱敏FEATURE_DATA_MASKING、只读连接FEATURE_INSTANCE_READ_ONLY_CONNECTION、外部密钥管理FEATURE_EXTERNAL_SECRET_MANAGER等实例级instance-gated功能。用户需要手动把激活额度分配给具体实例设置页也因此存在实例许可分配表InstanceAssignmentSheet这类面向分配操作的 UI。新发行的许可则是单一数字模型注册上限与激活上限相等即Instances ActiveInstances每个可注册的实例天然就是已激活的分配操作不再有意义。本计划的Goal一句话概括为让有效注册上限 ≤ 有效激活上限的许可在行为与呈现上都表现得像一个单数字实例许可。Architecture则明确了两条原则后端只添加一个集中式许可模式判定助手license-mode helper用它在不修改mutate已存储实例元数据的前提下计算有效激活前端订阅 Store 镜像同一有效上限比较规则使功能守卫feature guards与设置页在统一模式下隐藏面向分配的 UI而旧式拆分额度许可保持现状。Tech Stack覆盖 Go 后端服务与测试、Connect v1 API、Pinia/Vue 订阅 Store、React 设置页与组件、Vitest 前端测试。2. 统一判定规则核心逻辑与表驱动测试统一模式的判定只需一行比较func isUnifiedInstanceLimit(instanceLimit, activatedInstanceLimit int) bool { return instanceLimit activatedInstanceLimit }即当可注册的实例上限不超过可激活的实例上限时许可整体表现为统一模式。该纯函数位于 backend/enterprise/license.go当前仓库中已落地为isUnifiedInstanceLimit。计划要求以表驱动测试覆盖所有边界组合backend/enterprise/license_test.go包名enterprisepackage enterprise import ( math testing ) func TestIsUnifiedInstanceLimit(t *testing.T) { tests : []struct { name string instanceLimit int activatedLimit int want bool }{ {name: equal finite caps, instanceLimit: 10, activatedLimit: 10, want: true}, {name: activated cap larger than registration cap, instanceLimit: 10, activatedLimit: 20, want: true}, {name: split cap, instanceLimit: 50, activatedLimit: 20, want: false}, {name: unlimited both sides, instanceLimit: math.MaxInt, activatedLimit: math.MaxInt, want: true}, {name: unlimited registration finite activation, instanceLimit: math.MaxInt, activatedLimit: 20, want: false}, {name: finite registration unlimited activation, instanceLimit: 20, activatedLimit: math.MaxInt, want: true}, } for _, tt : range tests { t.Run(tt.name, func(t *testing.T) { if got : isUnifiedInstanceLimit(tt.instanceLimit, tt.activatedLimit); got ! tt.want { t.Fatalf(isUnifiedInstanceLimit(%d, %d) %v, want %v, tt.instanceLimit, tt.activatedLimit, got, tt.want) } }) } }六种组合的语义对照注册上限激活上限判定结果含义1010统一模式单数字许可新旧等额许可的典型形态1020统一模式激活额度充足所有可注册实例都可被激活5020拆分模式经典 split-cap需要分配激活额度无限无限统一模式两端均无上限无限20拆分模式可注册无限但可激活有限仍受分配约束20无限统一模式注册有限而激活无限实质也是单数字运行该测试按计划的 TDD 顺序先红后绿go test -v -count1 ./backend/enterprise -run ^TestIsUnifiedInstanceLimit$2.1 上限取值细节从订阅对象到整型上限判定使用的两个上限来自LicenseService的两个方法backend/enterprise/license.goGetInstanceLimit优先取订阅的Instances大于 0 时直接返回否则回落到plan.yaml中各计划的maximumInstanceCount其中 ENTERPRISE 计划配置为-1代码里会把-1归一化为math.MaxInt无限。可对照 backend/enterprise/plan.yaml 中 FREE/TEAM 为maximumInstanceCount: 10、ENTERPRISE 为-1的配置。GetActivatedInstanceLimit取订阅的ActiveInstances若小于 0 同样归一化为math.MaxInt。两个上限最终都归一化到int域做比较因此math.MaxInt作为无限的哨兵值贯穿始终。所有上限读取都经由LoadEffectiveSubscription该函数带有基于expirable.LRU的订阅缓存与singleflight防击穿缺失/无效/不可读的许可回落到 Free 计划。3. 后端 LicenseService统一模式助手与有效激活在纯函数之上计划新增两个面向业务的方法// IsUnifiedInstanceLicense returns whether every registrable instance is effectively activated. func (s *LicenseService) IsUnifiedInstanceLicense(ctx context.Context, workspaceID string) bool { return isUnifiedInstanceLimit( s.GetInstanceLimit(ctx, workspaceID), s.GetActivatedInstanceLimit(ctx, workspaceID), ) }当前仓库中还进一步封装了实例是否有效激活的判定IsInstanceEffectivelyActivated它把存储中的激活标志与统一许可模式做了或运算func (s *LicenseService) IsInstanceEffectivelyActivated(ctx context.Context, workspaceID string, instance *store.InstanceMessage) bool { if instance nil { return false } return instance.Metadata.GetActivation() || s.IsUnifiedInstanceLicense(ctx, workspaceID) }这意味着在统一模式下即使实例的存储元数据Activation: false也被视为已激活而在拆分模式下仍必须依赖实例自身的激活标志。3.1 功能门控IsFeatureEnabledForInstance 使用有效激活计划要求把IsFeatureEnabledForInstance的最终激活检查改为if s.IsUnifiedInstanceLicense(ctx, workspaceID) { return nil } if !instance.Metadata.GetActivation() { return errors.Errorf(feature %s is not available for instance %s, please assign license to the instance to enable it, f.String(), instance.ResourceID) } return nil即统一模式下不再检查存储激活标志、直接放行拆分模式下仍保留请为该实例分配许可的错误提示。当前仓库的实现通过IsInstanceEffectivelyActivated收敛了这一逻辑FREE 计划只做计划级检查不检查实例许可付费计划先做计划级功能检查再检查有效激活。计划配套的测试通过直接向LicenseService.cache注入订阅来构造场景利用同包测试可直取私有字段并模拟一个Activation: false的实例func newTestLicenseService(sub *v1pb.Subscription) *LicenseService { s : LicenseService{ cache: expirable.NewLRUstring, *v1pb.Subscription, } s.cache.Add(licenseCacheKey(test-workspace), sub) return s } func TestIsFeatureEnabledForInstanceUnifiedLicense(t *testing.T) { ctx : context.Background() instance : store.InstanceMessage{ ResourceID: prod, Workspace: test-workspace, Metadata: storepb.Instance{ Activation: false, }, } service : newTestLicenseService(v1pb.Subscription{ Plan: v1pb.PlanType_ENTERPRISE, Instances: 10, ActiveInstances: 10, }) if err : service.IsFeatureEnabledForInstance(ctx, test-workspace, v1pb.PlanFeature_FEATURE_DATA_MASKING, instance); err ! nil { t.Fatalf(unified license should enable feature for inactive stored instance: %v, err) } } func TestIsFeatureEnabledForInstanceSplitLicense(t *testing.T) { ctx : context.Background() instance : store.InstanceMessage{ ResourceID: prod, Workspace: test-workspace, Metadata: storepb.Instance{ Activation: false, }, } service : newTestLicenseService(v1pb.Subscription{ Plan: v1pb.PlanType_ENTERPRISE, Instances: 50, ActiveInstances: 20, }) if err : service.IsFeatureEnabledForInstance(ctx, test-workspace, v1pb.PlanFeature_FEATURE_DATA_MASKING, instance); err nil { t.Fatal(split license should still require stored activation) } }两个用例形成对照Instances10 / ActiveInstances10时未激活实例也可用脱敏功能Instances50 / ActiveInstances20时未激活实例被拒绝。3.2 发证侧回归CreateLicense 等额 Claims统一许可的发行端也需要回归保护签发许可时必须保证ActiveInstances与Instances相等。计划把CreateLicense中字面量的Claims构造抽取为独立函数并在发证时调用它func newLicenseClaims(params *LicenseParams) *Claims { return Claims{ Plan: params.Plan, Seats: params.Seats, ActiveInstances: params.Instances, Instances: params.Instances, WorkspaceID: params.WorkspaceID, } }c : newLicenseClaims(params)注意ActiveInstances直接取自params.Instances——这正是等额的保证点。配套回归测试func TestCreateLicenseUsesEqualInstanceClaims(t *testing.T) { claims : newLicenseClaims(LicenseParams{ Plan: v1pb.PlanType_ENTERPRISE.String(), Seats: 5, Instances: 10, WorkspaceID: test-workspace, }) if claims.Instances ! 10 { t.Fatalf(Instances %d, want 10, claims.Instances) } if claims.ActiveInstances ! 10 { t.Fatalf(ActiveInstances %d, want 10, claims.ActiveInstances) } }该函数与测试同样已落地于 backend/enterprise/license.go 与 backend/enterprise/license_test.go。许可证 JWT 的解析校验逻辑parseLicenseUncheckedExpiry会校验签名方法为 RSA、kid版本、iss/aud、计划类型与 workspaceId 归属最终把Claims映射为v1pb.Subscription的ActiveInstances/Instances/Seats等字段供上层统一读取。4. 实例与 Actuator API只算不存的有效激活后端 API 层的原则是响应中呈现有效激活但绝不改写存储。计划拆成三步。4.1 转换助手覆盖响应中的 Activation 字段在 backend/api/v1/instance_service_converter.go 增加一个轻量助手它先走既有转换、再覆盖激活字段func convertToV1InstanceWithEffectiveActivation(instance *store.InstanceMessage, effectiveActivation bool) *v1pb.Instance { result : convertToV1Instance(instance) result.Activation effectiveActivation return result }当前仓库中该文件的实际形态是convertToV1Instance(instance *store.InstanceMessage, activation bool)激活作为显式入参传入并写入响应对象的Activation字段而反向的convertToStoreInstance请求 → 存储仍原样保留请求带来的激活值——create/update 请求语义不受影响这正是不改存储的落点。4.2 InstanceService 响应转换统一模式下恒为已激活在 backend/api/v1/instance_service.go 增加服务方法把分散的响应转换调用点统一收敛func (s *InstanceService) convertToV1Instance(ctx context.Context, instance *store.InstanceMessage) *v1pb.Instance { if s.licenseService.IsUnifiedInstanceLicense(ctx, common.GetWorkspaceIDFromContext(ctx)) { return convertToV1InstanceWithEffectiveActivation(instance, true) } return convertToV1Instance(instance) }然后替换所有响应转换调用点例如把result : convertToV1Instance(instance)替换为result : s.convertToV1Instance(ctx, instance)列表场景同样处理ins : convertToV1Instance(instance)替换为ins : s.convertToV1Instance(ctx, instance)从当前仓库的 instance_service.go 可以看到GetInstance、CreateInstance、UpdateInstance、样本项目实例接口等都已统一走s.convertToV1Instance(ctx, ...)列表接口则直接调用convertToV1Instance(instance, s.licenseService.IsInstanceEffectivelyActivated(ctx, workspaceID, instance))。两种写法在统一模式下都等价地返回Activation true。4.3 配额检查统一模式跳过激活配额创建/更新实例时若触发了激活Metadata.Activation true原本会做激活配额校验统一模式下该校验应整体跳过。计划给出的守卫写法if instanceMessage.Metadata.GetActivation() !s.licenseService.IsUnifiedInstanceLicense(ctx, workspaceID) { activatedInstanceLimit : s.licenseService.GetActivatedInstanceLimit(ctx, workspaceID) count, err : s.store.GetActivatedInstanceCount(ctx, workspaceID) if err ! nil { return nil, connect.NewError(connect.CodeInternal, err) } if count activatedInstanceLimit { return nil, connect.NewError(connect.CodeResourceExhausted, errors.Errorf(instanceExceededError, activatedInstanceLimit)) } }更新路径同理以updateActivation !...IsUnifiedInstanceLicense(...)作为守卫。需要把原先无条件计算的activatedInstanceLimit : ...移入守卫分支内避免统一模式下无谓地读取额度。当前仓库把这段逻辑收敛为checkActivationLimit(ctx, workspaceID, activating bool)助手!activating || IsUnifiedInstanceLicense(...)时直接返回 nil否则计算GetActivatedInstanceCount并与GetActivatedInstanceLimit比较超限时返回connect.CodeResourceExhausted与instanceExceededErroractivation instance count has reached the limit (%v)。4.4 Actuator 统计统一模式下全部注册即全部激活Actuator 服务上报的ActivatedInstanceCount在统一模式下应等于全部实例数。计划给出activeInstanceCount, err : s.store.CountActiveInstances(ctx, workspaceID) if err ! nil { return nil, connect.NewError(connect.CodeInternal, errors.Wrapf(err, failed to count total instance)) } serverInfo.TotalInstanceCount int32(activeInstanceCount) if s.licenseService.IsUnifiedInstanceLicense(ctx, workspaceID) { serverInfo.ActivatedInstanceCount int32(activeInstanceCount) } else { activatedInstanceCount, err : s.store.GetActivatedInstanceCount(ctx, workspaceID) if err ! nil { return nil, connect.NewError(connect.CodeInternal, errors.Wrapf(err, failed to count activated instance)) } serverInfo.ActivatedInstanceCount int32(activatedInstanceCount) }这段逻辑在 backend/api/v1/actuator_service.go 已落地且保留了附近无关的 actuator 字段不受影响。这也解释了前端为何能通过totalInstanceCount activatedInstanceCount快速判断是否存在未分配许可的实例。4.5 编译级验证对 API 包做编译验证该包可能依赖外部服务无法直接跑单测时至少保证编译通过go test -v -count1 ./backend/api/v1 -run ^(TestNonExistent)$ # 若依赖外部服务无法干净运行退化为纯编译检查 go test -run ^$ ./backend/api/v15. 前端订阅 Store镜像同一有效上限规则前端核心是让订阅 Store 用与后端完全相同的规则派生出统一模式。计划给出的版本位于frontend/src/store/modules/v1/subscription.ts注意从当前仓库结构看该实现实际落在 frontend/src/stores/app/workspace.ts属于 Pinia store 体系其instanceCountLimit/instanceLicenseCount/hasUnifiedInstanceLicense的语义与计划一致在instanceLicenseCount之后新增派生值const hasUnifiedInstanceLicense computed(() { return instanceCountLimit.value instanceLicenseCount.value; });其中instanceCountLimit对应后端的GetInstanceLimit优先取订阅instances否则回落计划默认值instanceLicenseCount对应ActiveInstances小于 0 视为无限即Number.MAX_VALUE。比较式instanceCountLimit instanceLicenseCount与后端isUnifiedInstanceLimit完全一致。然后让功能守卫使用它。hasInstanceFeature更新为return checkInstanceFeature( currentPlan.value, feature, hasUnifiedInstanceLicense.value || instance.activation );instanceMissingLicense更新为if (hasUnifiedInstanceLicense.value) { return false; } return hasFeature(feature) !instance.activation;并把hasUnifiedInstanceLicense加入 Store 的返回 gettershasUnifiedInstanceLicense,对照当前仓库的 workspace.tshasUnifiedInstanceLicense为普通 getterinstanceMissingLicense已包含统一模式短路hasInstanceFeature使用hasUnifiedInstanceLicense() || instance.activation同时还派生了一个hasSplitInstanceLicense!isFreePlan() !hasUnifiedInstanceLicense()进一步印证拆分模式与统一模式互斥的模型。类型检查pnpm --dir frontend type-check6. 前端呈现层统一模式下隐藏分配型 UI呈现层的三条改动共同保证统一模式下用户不再看到任何分配许可的操作入口。6.1 订阅设置页单数字配额无分配表在 frontend/src/react/pages/settings/SubscriptionPage.tsx当前仓库对应 frontend/src/routes/workspace/SubscriptionPage.tsx读取 Store 模式const hasUnifiedInstanceLicense useVueState( () subscriptionStore.hasUnifiedInstanceLicense );传入InstanceLicenseStats并在 FREE 或统一模式下渲染单数字function InstanceLicenseStats({ planType, hasUnifiedInstanceLicense, instanceCountLimit, activatedCount, totalLicenseCount, onManageInstanceLicenses, }: { planType: string; hasUnifiedInstanceLicense: boolean; instanceCountLimit: number; activatedCount: number; totalLicenseCount: string; onManageInstanceLicenses: () void; }) { const { t } useTranslation(); if (planType FREE || hasUnifiedInstanceLicense) { return ( div classNameflex flex-col text-left dt classNametext-main{t(subscription.max-instance-count)}/dt div classNamemt-1 text-4xl{instanceCountLimit}/div /div ); }同时仅非统一模式渲染分配面板{!hasUnifiedInstanceLicense ( InstanceAssignmentSheet open{showInstanceAssignmentSheet} onOpenChange{setShowInstanceAssignmentSheet} / )}6.2 FeatureAttention无分配许可提示与动作在 frontend/src/react/components/FeatureAttention.tsx当前仓库对应 frontend/src/components/FeatureAttention.tsx读取模式const hasUnifiedInstanceLicense useVueState( () subscriptionStore.hasUnifiedInstanceLicense );是否存在未分配许可的实例的条件中加入统一模式否定const existInstanceWithoutLicense useVueState( () !subscriptionStore.hasUnifiedInstanceLicense actuatorStore.totalInstanceCount actuatorStore.activatedInstanceCount instanceLimitFeature.has(feature) );分配面板仅在非统一模式下渲染{!hasUnifiedInstanceLicense ( InstanceAssignmentSheet open{showInstanceAssignment} selectedInstanceList{instance ? [instance.name] : []} onOpenChange{setShowInstanceAssignment} / )}当前仓库实现与计划一致existInstanceWithoutLicense由!hasUnifiedInstanceLicense totalInstanceCount activatedInstanceCount instanceLimitFeature.has(feature)构成且actionText分支中分配许可文案同样以!hasUnifiedInstanceLicense为前提。6.3 实例表单隐藏激活开关在 frontend/src/react/components/instance/InstanceFormBody.tsx当前仓库对应 frontend/src/components/instance/InstanceFormBody.tsx读取模式const hasUnifiedInstanceLicense subscriptionStore.hasUnifiedInstanceLicense;激活开关的渲染条件收紧为{subscriptionStore.currentPlan ! PlanType.FREE !hasUnifiedInstanceLicense allowEdit (即FREE 之外、非统一模式、且有编辑权限时才展示激活开关。统一模式与 FREE 计划一样不再出现该开关。6.4 前端校验pnpm --dir frontend fix pnpm --dir frontend type-check pnpm --dir frontend test -- FeatureAttention7. 聚焦回归测试呈现层与 Store 双保险7.1 FeatureAttention 统一模式测试扩展 frontend/src/react/components/FeatureAttention.test.tsx在 mock 的订阅 Store 中增加hasUnifiedInstanceLicense字段beforeEach重置为false并新增用例test(does not show assignment attention in unified instance license mode, () { mocks.hasFeature.mockReturnValue(true); mocks.instanceMissingLicense.mockReturnValue(false); mocks.hasUnifiedInstanceLicense true; mocks.totalInstanceCount 2; mocks.activatedInstanceCount 2; render(FeatureAttention feature{PlanFeature.FEATURE_DATA_MASKING} /); expect(screen.queryByText(subscription.instance-assignment.assign-license)).not.toBeInTheDocument(); });当前仓库的 FeatureAttention.test.tsx 已包含hasUnifiedInstanceLicense相关的 mock 状态。7.2 Store 助手测试新增frontend/src/store/modules/v1/subscription.test.ts当前仓库对应为 app store 测试语义一致import { create } from bufbuild/protobuf; import { createPinia, setActivePinia } from pinia; import { beforeEach, describe, expect, test } from vitest; import { useSubscriptionV1Store } from ./subscription; import { InstanceSchema } from /types/proto-es/v1/instance_service_pb; import { PlanFeature, PlanType, SubscriptionSchema, } from /types/proto-es/v1/subscription_service_pb; describe(useSubscriptionV1Store unified instance license, () { beforeEach(() { setActivePinia(createPinia()); }); test(computes unified mode from effective limits, () { const store useSubscriptionV1Store(); store.setSubscription( create(SubscriptionSchema, { plan: PlanType.ENTERPRISE, instances: 10, activeInstances: 10, }) ); expect(store.hasUnifiedInstanceLicense).toBe(true); store.setSubscription( create(SubscriptionSchema, { plan: PlanType.ENTERPRISE, instances: 50, activeInstances: 20, }) ); expect(store.hasUnifiedInstanceLicense).toBe(false); }); test(does not report missing instance license in unified mode, () { const store useSubscriptionV1Store(); store.setSubscription( create(SubscriptionSchema, { plan: PlanType.ENTERPRISE, instances: 10, activeInstances: 10, }) ); const inactiveInstance create(InstanceSchema, { name: instances/prod, title: prod, activation: false, }); expect( store.instanceMissingLicense( PlanFeature.FEATURE_DATA_MASKING, inactiveInstance ) ).toBe(false); }); });用例覆盖两点10/10判定为统一模式、50/20判定为非统一模式统一模式下未激活实例不再报告缺许可。运行pnpm --dir frontend test -- FeatureAttention pnpm --dir frontend test -- subscription.test8. 任务清单与最终验证整份计划按 7 个任务推进可直接作为实施与评审的追踪清单Task 1 后端统一许可助手新增isUnifiedInstanceLimit纯函数与IsUnifiedInstanceLicense方法配表驱动测试backend/enterprise/license.go、backend/enterprise/license_test.go。Task 2 后端有效功能激活IsFeatureEnabledForInstance改用有效激活判定抽取newLicenseClaims并保证CreateLicense等额签发补两个门控测试与等额 claims 回归测试。Task 3 实例与 Actuator API 输出convertToV1InstanceWithEffectiveActivation覆盖响应激活统一模式下跳过激活配额检查Actuator 的ActivatedInstanceCount在统一模式下等于总实例数backend/api/v1/instance_service_converter.go、backend/api/v1/instance_service.go、backend/api/v1/actuator_service.go。Task 4 前端 Store 统一模式hasUnifiedInstanceLicense instanceCountLimit instanceLicenseCount并接入hasInstanceFeature/instanceMissingLicense。Task 5 前端呈现更新订阅页单数字配额且不渲染分配面板FeatureAttention 隐藏分配提示与动作实例表单隐藏激活开关不动无引用的WorkspaceInstanceLicenseStats.vue。Task 6 聚焦回归测试FeatureAttention 统一模式用例 Store 助手用例。Task 7 最终验证格式化、后端测试、lint、前端全量校验、后端构建、Git 状态检查。最终验证命令集按计划原文# Go 格式化 gofmt -w backend/enterprise/license.go backend/enterprise/license_test.go backend/api/v1/instance_service_converter.go backend/api/v1/instance_service.go backend/api/v1/actuator_service.go # 后端测试 go test -v -count1 ./backend/enterprise go test -run ^$ ./backend/api/v1 # Lint必要时先 --fix 再复跑 golangci-lint run --allow-parallel-runners # 前端全量校验 pnpm --dir frontend fix pnpm --dir frontend check pnpm --dir frontend type-check pnpm --dir frontend test # 后端构建 go build -ldflags -w -s -p16 -o ./bytebase-build/bytebase ./backend/bin/server/main.go # 状态确认 git status --short git log --oneline -59. 设计要点回顾单一判定规则贯穿前后端后端instanceLimit activatedInstanceLimit与前端instanceCountLimit instanceLicenseCount是同一规则的镜像实现任何一边改动都必须在另一边保持同步。只读计算、绝不落库有效激活只在 API 响应与功能门控层计算实例存储元数据中的Activation保持原样create/update 请求的激活语义不被覆盖。呈现层三处收敛设置页统计、功能提醒组件、实例表单的分配/激活入口统一以非统一模式为前提避免用户面对无意义的操作。测试覆盖双端后端以表驱动 注入缓存覆盖边界与门控前端以 Pinia mock 覆盖派生值与呈现行为最终以 lint、type-check、全量测试与构建收口。该方案对旧许可保持完全兼容只有满足注册上限 ≤ 激活上限的许可才进入统一模式历史上50/20这类拆分额度许可的分配行为、配额检查与 UI 均不受影响——这正是计划中legacy split-cap licenses keep current behavior的落点。【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Bytebase 统一实例许可Unified Instance License实现指南从后端判定到前端呈现的全链路落地【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase本文以 docs/superpowers/plans/2026-04-28-unified-instance-license.md 为骨架讲解 Bytebase 如何把注册实例数 ≤ 激活实例数的许可License统一表现为一个数字的实例许可模式后端只需一个集中式判定助手即可计算有效激活、不必改动存储中的实例元数据前端订阅 Store 同步镜像同一规则让功能开关与设置页在统一模式下隐藏分配assignment类 UI同时保留旧式拆分额度split-cap许可的既有行为。读完本文你将掌握这套方案的统一判定规则、Go 后端落地步骤、Connect v1 API 输出层改造、Pinia 订阅 Store 派生逻辑以及前后端回归测试的完整验证命令。1. 方案背景为什么要引入统一实例许可Bytebase 的实例许可Instance License历史上采用双额度模型一张许可同时携带**注册实例数Instances与激活实例数ActiveInstances**两个上限。注册额度决定工作区能接入多少实例激活额度决定其中有多少实例能启用数据脱敏FEATURE_DATA_MASKING、只读连接FEATURE_INSTANCE_READ_ONLY_CONNECTION、外部密钥管理FEATURE_EXTERNAL_SECRET_MANAGER等实例级instance-gated功能。用户需要手动把激活额度分配给具体实例设置页也因此存在实例许可分配表InstanceAssignmentSheet这类面向分配操作的 UI。新发行的许可则是单一数字模型注册上限与激活上限相等即Instances ActiveInstances每个可注册的实例天然就是已激活的分配操作不再有意义。本计划的Goal一句话概括为让有效注册上限 ≤ 有效激活上限的许可在行为与呈现上都表现得像一个单数字实例许可。Architecture则明确了两条原则后端只添加一个集中式许可模式判定助手license-mode helper用它在不修改mutate已存储实例元数据的前提下计算有效激活前端订阅 Store 镜像同一有效上限比较规则使功能守卫feature guards与设置页在统一模式下隐藏面向分配的 UI而旧式拆分额度许可保持现状。Tech Stack覆盖 Go 后端服务与测试、Connect v1 API、Pinia/Vue 订阅 Store、React 设置页与组件、Vitest 前端测试。2. 统一判定规则核心逻辑与表驱动测试统一模式的判定只需一行比较func isUnifiedInstanceLimit(instanceLimit, activatedInstanceLimit int) bool { return instanceLimit activatedInstanceLimit }即当可注册的实例上限不超过可激活的实例上限时许可整体表现为统一模式。该纯函数位于 backend/enterprise/license.go当前仓库中已落地为isUnifiedInstanceLimit。计划要求以表驱动测试覆盖所有边界组合backend/enterprise/license_test.go包名enterprisepackage enterprise import ( math testing ) func TestIsUnifiedInstanceLimit(t *testing.T) { tests : []struct { name string instanceLimit int activatedLimit int want bool }{ {name: equal finite caps, instanceLimit: 10, activatedLimit: 10, want: true}, {name: activated cap larger than registration cap, instanceLimit: 10, activatedLimit: 20, want: true}, {name: split cap, instanceLimit: 50, activatedLimit: 20, want: false}, {name: unlimited both sides, instanceLimit: math.MaxInt, activatedLimit: math.MaxInt, want: true}, {name: unlimited registration finite activation, instanceLimit: math.MaxInt, activatedLimit: 20, want: false}, {name: finite registration unlimited activation, instanceLimit: 20, activatedLimit: math.MaxInt, want: true}, } for _, tt : range tests { t.Run(tt.name, func(t *testing.T) { if got : isUnifiedInstanceLimit(tt.instanceLimit, tt.activatedLimit); got ! tt.want { t.Fatalf(isUnifiedInstanceLimit(%d, %d) %v, want %v, tt.instanceLimit, tt.activatedLimit, got, tt.want) } }) } }六种组合的语义对照注册上限激活上限判定结果含义1010统一模式单数字许可新旧等额许可的典型形态1020统一模式激活额度充足所有可注册实例都可被激活5020拆分模式经典 split-cap需要分配激活额度无限无限统一模式两端均无上限无限20拆分模式可注册无限但可激活有限仍受分配约束20无限统一模式注册有限而激活无限实质也是单数字运行该测试按计划的 TDD 顺序先红后绿go test -v -count1 ./backend/enterprise -run ^TestIsUnifiedInstanceLimit$2.1 上限取值细节从订阅对象到整型上限判定使用的两个上限来自LicenseService的两个方法backend/enterprise/license.goGetInstanceLimit优先取订阅的Instances大于 0 时直接返回否则回落到plan.yaml中各计划的maximumInstanceCount其中 ENTERPRISE 计划配置为-1代码里会把-1归一化为math.MaxInt无限。可对照 backend/enterprise/plan.yaml 中 FREE/TEAM 为maximumInstanceCount: 10、ENTERPRISE 为-1的配置。GetActivatedInstanceLimit取订阅的ActiveInstances若小于 0 同样归一化为math.MaxInt。两个上限最终都归一化到int域做比较因此math.MaxInt作为无限的哨兵值贯穿始终。所有上限读取都经由LoadEffectiveSubscription该函数带有基于expirable.LRU的订阅缓存与singleflight防击穿缺失/无效/不可读的许可回落到 Free 计划。3. 后端 LicenseService统一模式助手与有效激活在纯函数之上计划新增两个面向业务的方法// IsUnifiedInstanceLicense returns whether every registrable instance is effectively activated. func (s *LicenseService) IsUnifiedInstanceLicense(ctx context.Context, workspaceID string) bool { return isUnifiedInstanceLimit( s.GetInstanceLimit(ctx, workspaceID), s.GetActivatedInstanceLimit(ctx, workspaceID), ) }当前仓库中还进一步封装了实例是否有效激活的判定IsInstanceEffectivelyActivated它把存储中的激活标志与统一许可模式做了或运算func (s *LicenseService) IsInstanceEffectivelyActivated(ctx context.Context, workspaceID string, instance *store.InstanceMessage) bool { if instance nil { return false } return instance.Metadata.GetActivation() || s.IsUnifiedInstanceLicense(ctx, workspaceID) }这意味着在统一模式下即使实例的存储元数据Activation: false也被视为已激活而在拆分模式下仍必须依赖实例自身的激活标志。3.1 功能门控IsFeatureEnabledForInstance 使用有效激活计划要求把IsFeatureEnabledForInstance的最终激活检查改为if s.IsUnifiedInstanceLicense(ctx, workspaceID) { return nil } if !instance.Metadata.GetActivation() { return errors.Errorf(feature %s is not available for instance %s, please assign license to the instance to enable it, f.String(), instance.ResourceID) } return nil即统一模式下不再检查存储激活标志、直接放行拆分模式下仍保留请为该实例分配许可的错误提示。当前仓库的实现通过IsInstanceEffectivelyActivated收敛了这一逻辑FREE 计划只做计划级检查不检查实例许可付费计划先做计划级功能检查再检查有效激活。计划配套的测试通过直接向LicenseService.cache注入订阅来构造场景利用同包测试可直取私有字段并模拟一个Activation: false的实例func newTestLicenseService(sub *v1pb.Subscription) *LicenseService { s : LicenseService{ cache: expirable.NewLRUstring, *v1pb.Subscription, } s.cache.Add(licenseCacheKey(test-workspace), sub) return s } func TestIsFeatureEnabledForInstanceUnifiedLicense(t *testing.T) { ctx : context.Background() instance : store.InstanceMessage{ ResourceID: prod, Workspace: test-workspace, Metadata: storepb.Instance{ Activation: false, }, } service : newTestLicenseService(v1pb.Subscription{ Plan: v1pb.PlanType_ENTERPRISE, Instances: 10, ActiveInstances: 10, }) if err : service.IsFeatureEnabledForInstance(ctx, test-workspace, v1pb.PlanFeature_FEATURE_DATA_MASKING, instance); err ! nil { t.Fatalf(unified license should enable feature for inactive stored instance: %v, err) } } func TestIsFeatureEnabledForInstanceSplitLicense(t *testing.T) { ctx : context.Background() instance : store.InstanceMessage{ ResourceID: prod, Workspace: test-workspace, Metadata: storepb.Instance{ Activation: false, }, } service : newTestLicenseService(v1pb.Subscription{ Plan: v1pb.PlanType_ENTERPRISE, Instances: 50, ActiveInstances: 20, }) if err : service.IsFeatureEnabledForInstance(ctx, test-workspace, v1pb.PlanFeature_FEATURE_DATA_MASKING, instance); err nil { t.Fatal(split license should still require stored activation) } }两个用例形成对照Instances10 / ActiveInstances10时未激活实例也可用脱敏功能Instances50 / ActiveInstances20时未激活实例被拒绝。3.2 发证侧回归CreateLicense 等额 Claims统一许可的发行端也需要回归保护签发许可时必须保证ActiveInstances与Instances相等。计划把CreateLicense中字面量的Claims构造抽取为独立函数并在发证时调用它func newLicenseClaims(params *LicenseParams) *Claims { return Claims{ Plan: params.Plan, Seats: params.Seats, ActiveInstances: params.Instances, Instances: params.Instances, WorkspaceID: params.WorkspaceID, } }c : newLicenseClaims(params)注意ActiveInstances直接取自params.Instances——这正是等额的保证点。配套回归测试func TestCreateLicenseUsesEqualInstanceClaims(t *testing.T) { claims : newLicenseClaims(LicenseParams{ Plan: v1pb.PlanType_ENTERPRISE.String(), Seats: 5, Instances: 10, WorkspaceID: test-workspace, }) if claims.Instances ! 10 { t.Fatalf(Instances %d, want 10, claims.Instances) } if claims.ActiveInstances ! 10 { t.Fatalf(ActiveInstances %d, want 10, claims.ActiveInstances) } }该函数与测试同样已落地于 backend/enterprise/license.go 与 backend/enterprise/license_test.go。许可证 JWT 的解析校验逻辑parseLicenseUncheckedExpiry会校验签名方法为 RSA、kid版本、iss/aud、计划类型与 workspaceId 归属最终把Claims映射为v1pb.Subscription的ActiveInstances/Instances/Seats等字段供上层统一读取。4. 实例与 Actuator API只算不存的有效激活后端 API 层的原则是响应中呈现有效激活但绝不改写存储。计划拆成三步。4.1 转换助手覆盖响应中的 Activation 字段在 backend/api/v1/instance_service_converter.go 增加一个轻量助手它先走既有转换、再覆盖激活字段func convertToV1InstanceWithEffectiveActivation(instance *store.InstanceMessage, effectiveActivation bool) *v1pb.Instance { result : convertToV1Instance(instance) result.Activation effectiveActivation return result }当前仓库中该文件的实际形态是convertToV1Instance(instance *store.InstanceMessage, activation bool)激活作为显式入参传入并写入响应对象的Activation字段而反向的convertToStoreInstance请求 → 存储仍原样保留请求带来的激活值——create/update 请求语义不受影响这正是不改存储的落点。4.2 InstanceService 响应转换统一模式下恒为已激活在 backend/api/v1/instance_service.go 增加服务方法把分散的响应转换调用点统一收敛func (s *InstanceService) convertToV1Instance(ctx context.Context, instance *store.InstanceMessage) *v1pb.Instance { if s.licenseService.IsUnifiedInstanceLicense(ctx, common.GetWorkspaceIDFromContext(ctx)) { return convertToV1InstanceWithEffectiveActivation(instance, true) } return convertToV1Instance(instance) }然后替换所有响应转换调用点例如把result : convertToV1Instance(instance)替换为result : s.convertToV1Instance(ctx, instance)列表场景同样处理ins : convertToV1Instance(instance)替换为ins : s.convertToV1Instance(ctx, instance)从当前仓库的 instance_service.go 可以看到GetInstance、CreateInstance、UpdateInstance、样本项目实例接口等都已统一走s.convertToV1Instance(ctx, ...)列表接口则直接调用convertToV1Instance(instance, s.licenseService.IsInstanceEffectivelyActivated(ctx, workspaceID, instance))。两种写法在统一模式下都等价地返回Activation true。4.3 配额检查统一模式跳过激活配额创建/更新实例时若触发了激活Metadata.Activation true原本会做激活配额校验统一模式下该校验应整体跳过。计划给出的守卫写法if instanceMessage.Metadata.GetActivation() !s.licenseService.IsUnifiedInstanceLicense(ctx, workspaceID) { activatedInstanceLimit : s.licenseService.GetActivatedInstanceLimit(ctx, workspaceID) count, err : s.store.GetActivatedInstanceCount(ctx, workspaceID) if err ! nil { return nil, connect.NewError(connect.CodeInternal, err) } if count activatedInstanceLimit { return nil, connect.NewError(connect.CodeResourceExhausted, errors.Errorf(instanceExceededError, activatedInstanceLimit)) } }更新路径同理以updateActivation !...IsUnifiedInstanceLicense(...)作为守卫。需要把原先无条件计算的activatedInstanceLimit : ...移入守卫分支内避免统一模式下无谓地读取额度。当前仓库把这段逻辑收敛为checkActivationLimit(ctx, workspaceID, activating bool)助手!activating || IsUnifiedInstanceLicense(...)时直接返回 nil否则计算GetActivatedInstanceCount并与GetActivatedInstanceLimit比较超限时返回connect.CodeResourceExhausted与instanceExceededErroractivation instance count has reached the limit (%v)。4.4 Actuator 统计统一模式下全部注册即全部激活Actuator 服务上报的ActivatedInstanceCount在统一模式下应等于全部实例数。计划给出activeInstanceCount, err : s.store.CountActiveInstances(ctx, workspaceID) if err ! nil { return nil, connect.NewError(connect.CodeInternal, errors.Wrapf(err, failed to count total instance)) } serverInfo.TotalInstanceCount int32(activeInstanceCount) if s.licenseService.IsUnifiedInstanceLicense(ctx, workspaceID) { serverInfo.ActivatedInstanceCount int32(activeInstanceCount) } else { activatedInstanceCount, err : s.store.GetActivatedInstanceCount(ctx, workspaceID) if err ! nil { return nil, connect.NewError(connect.CodeInternal, errors.Wrapf(err, failed to count activated instance)) } serverInfo.ActivatedInstanceCount int32(activatedInstanceCount) }这段逻辑在 backend/api/v1/actuator_service.go 已落地且保留了附近无关的 actuator 字段不受影响。这也解释了前端为何能通过totalInstanceCount activatedInstanceCount快速判断是否存在未分配许可的实例。4.5 编译级验证对 API 包做编译验证该包可能依赖外部服务无法直接跑单测时至少保证编译通过go test -v -count1 ./backend/api/v1 -run ^(TestNonExistent)$ # 若依赖外部服务无法干净运行退化为纯编译检查 go test -run ^$ ./backend/api/v15. 前端订阅 Store镜像同一有效上限规则前端核心是让订阅 Store 用与后端完全相同的规则派生出统一模式。计划给出的版本位于frontend/src/store/modules/v1/subscription.ts注意从当前仓库结构看该实现实际落在 frontend/src/stores/app/workspace.ts属于 Pinia store 体系其instanceCountLimit/instanceLicenseCount/hasUnifiedInstanceLicense的语义与计划一致在instanceLicenseCount之后新增派生值const hasUnifiedInstanceLicense computed(() { return instanceCountLimit.value instanceLicenseCount.value; });其中instanceCountLimit对应后端的GetInstanceLimit优先取订阅instances否则回落计划默认值instanceLicenseCount对应ActiveInstances小于 0 视为无限即Number.MAX_VALUE。比较式instanceCountLimit instanceLicenseCount与后端isUnifiedInstanceLimit完全一致。然后让功能守卫使用它。hasInstanceFeature更新为return checkInstanceFeature( currentPlan.value, feature, hasUnifiedInstanceLicense.value || instance.activation );instanceMissingLicense更新为if (hasUnifiedInstanceLicense.value) { return false; } return hasFeature(feature) !instance.activation;并把hasUnifiedInstanceLicense加入 Store 的返回 gettershasUnifiedInstanceLicense,对照当前仓库的 workspace.tshasUnifiedInstanceLicense为普通 getterinstanceMissingLicense已包含统一模式短路hasInstanceFeature使用hasUnifiedInstanceLicense() || instance.activation同时还派生了一个hasSplitInstanceLicense!isFreePlan() !hasUnifiedInstanceLicense()进一步印证拆分模式与统一模式互斥的模型。类型检查pnpm --dir frontend type-check6. 前端呈现层统一模式下隐藏分配型 UI呈现层的三条改动共同保证统一模式下用户不再看到任何分配许可的操作入口。6.1 订阅设置页单数字配额无分配表在 frontend/src/react/pages/settings/SubscriptionPage.tsx当前仓库对应 frontend/src/routes/workspace/SubscriptionPage.tsx读取 Store 模式const hasUnifiedInstanceLicense useVueState( () subscriptionStore.hasUnifiedInstanceLicense );传入InstanceLicenseStats并在 FREE 或统一模式下渲染单数字function InstanceLicenseStats({ planType, hasUnifiedInstanceLicense, instanceCountLimit, activatedCount, totalLicenseCount, onManageInstanceLicenses, }: { planType: string; hasUnifiedInstanceLicense: boolean; instanceCountLimit: number; activatedCount: number; totalLicenseCount: string; onManageInstanceLicenses: () void; }) { const { t } useTranslation(); if (planType FREE || hasUnifiedInstanceLicense) { return ( div classNameflex flex-col text-left dt classNametext-main{t(subscription.max-instance-count)}/dt div classNamemt-1 text-4xl{instanceCountLimit}/div /div ); }同时仅非统一模式渲染分配面板{!hasUnifiedInstanceLicense ( InstanceAssignmentSheet open{showInstanceAssignmentSheet} onOpenChange{setShowInstanceAssignmentSheet} / )}6.2 FeatureAttention无分配许可提示与动作在 frontend/src/react/components/FeatureAttention.tsx当前仓库对应 frontend/src/components/FeatureAttention.tsx读取模式const hasUnifiedInstanceLicense useVueState( () subscriptionStore.hasUnifiedInstanceLicense );是否存在未分配许可的实例的条件中加入统一模式否定const existInstanceWithoutLicense useVueState( () !subscriptionStore.hasUnifiedInstanceLicense actuatorStore.totalInstanceCount actuatorStore.activatedInstanceCount instanceLimitFeature.has(feature) );分配面板仅在非统一模式下渲染{!hasUnifiedInstanceLicense ( InstanceAssignmentSheet open{showInstanceAssignment} selectedInstanceList{instance ? [instance.name] : []} onOpenChange{setShowInstanceAssignment} / )}当前仓库实现与计划一致existInstanceWithoutLicense由!hasUnifiedInstanceLicense totalInstanceCount activatedInstanceCount instanceLimitFeature.has(feature)构成且actionText分支中分配许可文案同样以!hasUnifiedInstanceLicense为前提。6.3 实例表单隐藏激活开关在 frontend/src/react/components/instance/InstanceFormBody.tsx当前仓库对应 frontend/src/components/instance/InstanceFormBody.tsx读取模式const hasUnifiedInstanceLicense subscriptionStore.hasUnifiedInstanceLicense;激活开关的渲染条件收紧为{subscriptionStore.currentPlan ! PlanType.FREE !hasUnifiedInstanceLicense allowEdit (即FREE 之外、非统一模式、且有编辑权限时才展示激活开关。统一模式与 FREE 计划一样不再出现该开关。6.4 前端校验pnpm --dir frontend fix pnpm --dir frontend type-check pnpm --dir frontend test -- FeatureAttention7. 聚焦回归测试呈现层与 Store 双保险7.1 FeatureAttention 统一模式测试扩展 frontend/src/react/components/FeatureAttention.test.tsx在 mock 的订阅 Store 中增加hasUnifiedInstanceLicense字段beforeEach重置为false并新增用例test(does not show assignment attention in unified instance license mode, () { mocks.hasFeature.mockReturnValue(true); mocks.instanceMissingLicense.mockReturnValue(false); mocks.hasUnifiedInstanceLicense true; mocks.totalInstanceCount 2; mocks.activatedInstanceCount 2; render(FeatureAttention feature{PlanFeature.FEATURE_DATA_MASKING} /); expect(screen.queryByText(subscription.instance-assignment.assign-license)).not.toBeInTheDocument(); });当前仓库的 FeatureAttention.test.tsx 已包含hasUnifiedInstanceLicense相关的 mock 状态。7.2 Store 助手测试新增frontend/src/store/modules/v1/subscription.test.ts当前仓库对应为 app store 测试语义一致import { create } from bufbuild/protobuf; import { createPinia, setActivePinia } from pinia; import { beforeEach, describe, expect, test } from vitest; import { useSubscriptionV1Store } from ./subscription; import { InstanceSchema } from /types/proto-es/v1/instance_service_pb; import { PlanFeature, PlanType, SubscriptionSchema, } from /types/proto-es/v1/subscription_service_pb; describe(useSubscriptionV1Store unified instance license, () { beforeEach(() { setActivePinia(createPinia()); }); test(computes unified mode from effective limits, () { const store useSubscriptionV1Store(); store.setSubscription( create(SubscriptionSchema, { plan: PlanType.ENTERPRISE, instances: 10, activeInstances: 10, }) ); expect(store.hasUnifiedInstanceLicense).toBe(true); store.setSubscription( create(SubscriptionSchema, { plan: PlanType.ENTERPRISE, instances: 50, activeInstances: 20, }) ); expect(store.hasUnifiedInstanceLicense).toBe(false); }); test(does not report missing instance license in unified mode, () { const store useSubscriptionV1Store(); store.setSubscription( create(SubscriptionSchema, { plan: PlanType.ENTERPRISE, instances: 10, activeInstances: 10, }) ); const inactiveInstance create(InstanceSchema, { name: instances/prod, title: prod, activation: false, }); expect( store.instanceMissingLicense( PlanFeature.FEATURE_DATA_MASKING, inactiveInstance ) ).toBe(false); }); });用例覆盖两点10/10判定为统一模式、50/20判定为非统一模式统一模式下未激活实例不再报告缺许可。运行pnpm --dir frontend test -- FeatureAttention pnpm --dir frontend test -- subscription.test8. 任务清单与最终验证整份计划按 7 个任务推进可直接作为实施与评审的追踪清单Task 1 后端统一许可助手新增isUnifiedInstanceLimit纯函数与IsUnifiedInstanceLicense方法配表驱动测试backend/enterprise/license.go、backend/enterprise/license_test.go。Task 2 后端有效功能激活IsFeatureEnabledForInstance改用有效激活判定抽取newLicenseClaims并保证CreateLicense等额签发补两个门控测试与等额 claims 回归测试。Task 3 实例与 Actuator API 输出convertToV1InstanceWithEffectiveActivation覆盖响应激活统一模式下跳过激活配额检查Actuator 的ActivatedInstanceCount在统一模式下等于总实例数backend/api/v1/instance_service_converter.go、backend/api/v1/instance_service.go、backend/api/v1/actuator_service.go。Task 4 前端 Store 统一模式hasUnifiedInstanceLicense instanceCountLimit instanceLicenseCount并接入hasInstanceFeature/instanceMissingLicense。Task 5 前端呈现更新订阅页单数字配额且不渲染分配面板FeatureAttention 隐藏分配提示与动作实例表单隐藏激活开关不动无引用的WorkspaceInstanceLicenseStats.vue。Task 6 聚焦回归测试FeatureAttention 统一模式用例 Store 助手用例。Task 7 最终验证格式化、后端测试、lint、前端全量校验、后端构建、Git 状态检查。最终验证命令集按计划原文# Go 格式化 gofmt -w backend/enterprise/license.go backend/enterprise/license_test.go backend/api/v1/instance_service_converter.go backend/api/v1/instance_service.go backend/api/v1/actuator_service.go # 后端测试 go test -v -count1 ./backend/enterprise go test -run ^$ ./backend/api/v1 # Lint必要时先 --fix 再复跑 golangci-lint run --allow-parallel-runners # 前端全量校验 pnpm --dir frontend fix pnpm --dir frontend check pnpm --dir frontend type-check pnpm --dir frontend test # 后端构建 go build -ldflags -w -s -p16 -o ./bytebase-build/bytebase ./backend/bin/server/main.go # 状态确认 git status --short git log --oneline -59. 设计要点回顾单一判定规则贯穿前后端后端instanceLimit activatedInstanceLimit与前端instanceCountLimit instanceLicenseCount是同一规则的镜像实现任何一边改动都必须在另一边保持同步。只读计算、绝不落库有效激活只在 API 响应与功能门控层计算实例存储元数据中的Activation保持原样create/update 请求的激活语义不被覆盖。呈现层三处收敛设置页统计、功能提醒组件、实例表单的分配/激活入口统一以非统一模式为前提避免用户面对无意义的操作。测试覆盖双端后端以表驱动 注入缓存覆盖边界与门控前端以 Pinia mock 覆盖派生值与呈现行为最终以 lint、type-check、全量测试与构建收口。该方案对旧许可保持完全兼容只有满足注册上限 ≤ 激活上限的许可才进入统一模式历史上50/20这类拆分额度许可的分配行为、配额检查与 UI 均不受影响——这正是计划中legacy split-cap licenses keep current behavior的落点。【免费下载链接】bytebaseDatabase governance built for humans and agents — controlling changes and access across every major database.项目地址: https://gitcode.com/GitHub_Trending/by/bytebase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
