CyreneAdmin 1.5.0 正式发布。这一版本没有停留在单个功能点的增加，而是同时覆盖国际化、端到端测试、请求鉴权修复以及前后端依赖升级。对于基于脚手架构建企业级后台的团队来说，这些变化会直接影响项目的可维护性、交付验证和后续升级成本。
CyreneAdmin 继续同时支持 Spring Boot 与 Solon，并提供权限控制、用户管理、菜单配置、操作日志等后台系统常见能力。升级到 1.5.0 时，建议把它看作一次工程基础设施更新，而不只是简单替换版本号。
i18n 不只是翻译菜单
后台系统的国际化通常会涉及多个层面：菜单名称、按钮文案、表单校验提示、接口错误消息以及登录和权限相关提示。如果只替换静态页面中的少量文本，后续新增模块时仍然容易出现中英文混杂、文案散落和重复翻译的问题。
可以在前端将用户可见文本集中到语言资源中，并让组件通过统一的 key 获取文案。下面是一个可以改造到常见前端项目中的最小示例，假设项目使用 TypeScript 和 Vue 风格的 $t 方法：
// src/locales/zh-CN.ts
export default {
auth: {
unauthorized: '登录状态已失效，请重新登录',
},
common: {
save: '保存',
cancel: '取消',
},
}
// src/locales/en-US.ts
export default {
auth: {
unauthorized: 'Your session has expired. Please sign in again.',
},
common: {
save: 'Save',
cancel: 'Cancel',
},
}
<template>
<button type="button" @click="save">
{{ $t('common.save') }}
</button>
<p v-if="expired">{{ $t('auth.unauthorized') }}</p>
</template>
实践时应尽量让权限失败、请求失败等公共场景也使用语言资源，而不是在拦截器或业务组件中硬编码中文。这样切换语言时，用户看到的错误提示和页面内容才会保持一致。
E2E 验证覆盖真实用户路径
1.5.0 的更新包含完善 E2E 验证范围。E2E 测试的价值不在于把每个函数都重复测试一遍，而在于验证用户从浏览器进入系统后，关键链路是否可以完整走通，例如登录、菜单加载、权限控制和退出登录。
可以使用 Playwright 为登录链路建立一个最小测试。下面的示例假设系统提供 /login 页面，并在成功登录后跳转到 /dashboard；实际选择器需要根据项目页面调整：
// tests/e2e/login.spec.ts
import { test, expect } from '@playwright/test'
test('user can sign in and reach the dashboard', async ({ page }) => {
await page.goto('http://localhost:3000/login')
await page.getByLabel('Username').fill(process.env.E2E_USERNAME ?? 'admin')
await page.getByLabel('Password').fill(process.env.E2E_PASSWORD ?? 'change-me')
await page.getByRole('button', { name: /sign in|登录/i }).click()
await expect(page).toHaveURL(/dashboard/)
await expect(page.getByText(/dashboard|仪表盘/i)).toBeVisible()
})
运行方式可以保持简单：
npm install
npx playwright install --with-deps
E2E_USERNAME=admin E2E_PASSWORD='change-me' npx playwright test tests/e2e/login.spec.ts
在真实项目中，还应把未登录访问受保护页面、无权限用户访问菜单、接口返回未授权、切换语言后刷新页面等场景加入验证范围。E2E 测试需要稳定的测试账号和可重复的数据，否则失败结果很难区分是代码回归还是环境污染。
Authorization 请求头修复的影响
本版本修复了请求头 name 为 Authorization 的问题。这个修复看似细小，但它位于前端请求封装、后端认证过滤器和网关转发之间，任何一环的字段名称不一致，都可能表现为“登录成功但接口全部返回未授权”。
客户端应统一在请求拦截器中设置 Bearer Token，并避免在多个业务模块里重复拼接：
// src/http/interceptor.ts
export function applyAuthHeader(
headers: Record<string, string>,
token: string | null,
) {
if (token) {
headers.Authorization = `Bearer ${token}`
}
return headers
}
可以使用 curl 快速检查后端是否正确接收该请求头。将地址和 Token 替换为本地环境中的值：
curl -i \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Accept: application/json" \
http://localhost:8080/api/user/profile
验证时要同时关注大小写、Bearer 前缀、代理是否转发该请求头，以及 Spring Boot 或 Solon 应用的认证组件是否读取了同一个字段。不要仅凭浏览器中看到 Token 就判断鉴权链路正常。
前后端依赖升级如何落地
CyreneAdmin 1.5.0 同步升级前后端依赖。依赖升级通常会带来安全修复、构建工具改进和兼容性变化，但也可能影响路由、请求库、测试运行器或后端配置。因此，升级动作应与构建、单元测试和 E2E 测试绑定执行。
可以把升级后的检查流程固化为脚本：
#!/usr/bin/env bash
set -euo pipefail
npm ci
npm run lint
npm run build
npm test -- --runInBand
npx playwright test
# 后端命令按项目实际构建工具选择其一
./mvnw test
# 或：./gradlew test
Spring Boot 与 Solon 是两条不同的运行路径。业务模块可以共享接口契约、权限模型和测试数据设计，但启动方式、依赖管理和 Web 层适配不能想当然地完全相同。升级后应分别验证两种后端实现，尤其是认证过滤器、跨域配置、异常响应格式和操作日志等公共能力。
升级建议
对于已经使用 CyreneAdmin 的项目，可以按下面的顺序完成升级：
- 记录当前前端、Spring Boot 或 Solon 后端的依赖版本和构建命令。
- 升级到 1.5.0 后，检查语言资源是否覆盖登录、权限和请求错误等公共文案。
- 使用浏览器或 curl 验证
Authorization: Bearer ...请求头在代理和后端之间没有丢失。 - 执行构建、单元测试和 E2E 测试，并重点观察登录、菜单权限和登出流程。
- 在预发布环境分别启动 Spring Boot 与 Solon 实现，确认接口响应和认证行为符合原有契约。
1.5.0 的价值在于把后台系统的“能运行”进一步推进到“可验证、可扩展、可国际化”。如果项目准备服务多地区用户，或者即将进入持续交付阶段，i18n 资源整理、E2E 场景补齐和依赖升级后的回归验证应当一起纳入发布标准。