提到合规，多数前端团队的第一反应是"这是后端和安全部门的事"。但 GDPR 对数据处理透明度的要求、等保 2.0 对身份鉴别和安全审计的要求，很多控制点恰恰落在前端：表单收集了什么字段、Cookie 如何征得同意、页面埋点传了哪些数据、操作日志怎么留痕，这些都在 Vue 3 项目的掌控范围内。合规审计失败的项目，往往不是缺一个安全组件，而是缺一套把合规要求固化为工程约束的机制。
一、把 GDPR 的数据最小化原则落到前端代码层
GDPR 最核心的原则之一是数据最小化：只收集业务必需的个人数据，且使用目的必须明确。落到 Vue 3 项目里，首先要做的是建立一份敏感字段清单，并让清单"可执行"。很多团队的清单躺在 Confluence 里没人看，正确的做法是把它变成代码约束——例如通过自定义指令或工具函数，强制对身份证号、手机号、邮箱等字段做脱敏渲染，避免敏感数据以明文出现在 DOM 中，被截图、录屏或浏览器插件读取。
下面是一个基于 Vue 3 自定义指令的脱敏方案，在模板层面统一处理，避免各页面各写一套：
// directives/mask.ts
import type { Directive } from 'vue'
const strategies: Record<string, (v: string) => string> = {
phone: v => v.replace(/(\d{3})\d{4}(\d{4})/, '$1****$2'),
idcard: v => v.replace(/(\d{6})\d{8}(\w{4})/, '$1********$2'),
email: v => v.replace(/(^.).*(@.*$)/, '$1***$2')
}
export const vMask: Directive = {
mounted(el, binding) {
const fn = strategies[binding.arg]
if (fn && typeof el.textContent === 'string') {
el.textContent = fn(el.textContent)
}
}
}除了展示层，数据采集环节同样需要治理。表单组件应通过集中式的 schema 定义哪些字段允许收集，并在 code review 阶段检查新增字段是否在清单中登记。对于 localStorage 和 sessionStorage，建议封装统一的存储模块，禁止直接使用原生 API 写入个人数据，同时在模块内做加密和过期清理。审计时如果能出示"所有敏感字段必须经过 schema 注册"的规范与对应 lint 规则，就是很有说服力的证据。
二、Cookie 同意与第三方依赖的透明度治理
GDPR 要求在用户明确同意之前，不得写入非必要 Cookie，也不得向第三方传输个人数据。这对前端意味着三件事：同意管理横幅的逻辑要前置、第三方 SDK 的加载要受控、埋点上报要可审计。推荐把"同意状态"做成一个全局的 composable，所有依赖追踪的第三方脚本（统计、广告、客服）都通过它决定是否初始化：
// composables/useConsent.ts
import { ref } from 'vue'
const consent = ref(JSON.parse(localStorage.getItem('gdpr-consent') || '{"analytics":false}'))
export function useConsent() {
const grant = (key: string) => {
consent.value[key] = true
localStorage.setItem('gdpr-consent', JSON.stringify(consent.value))
}
const isAllowed = (key: string) => !!consent.value[key]
return { consent, grant, isAllowed }
}依赖治理方面，等保和 GDPR 都隐含了供应链安全的要求。建议在 CI 中引入 npm audit 或 Snyk 扫描，并对新增依赖做准入审查：这个包会往哪些域名发请求？是否有遥测代码？可以通过静态分析工具检查构建产物中的外链域名，生成"外呼清单"作为审计材料。一个常见误区是只在生产环境禁用了某 SDK，但预发环境的日志里仍然在明文上报用户行为，审计取证时两边都会被查。
三、等保视角下的身份鉴别、会话安全与操作留痕
等保 2.0 三级要求中与前端直接相关的包括：身份标识唯一且复杂度校验、登录失败处理、会话超时自动退出、安全审计日志留存。这些点在 Vue 3 项目中可以通过路由守卫和请求拦截器系统性实现。比如全局路由守卫统一做登录态校验与超时判断，避免每个页面各自为政：
// router/guard.ts
const IDLE_LIMIT = 15 * 60 * 1000 // 会话空闲上限，等保要求可配置
let lastActive = Date.now()
window.addEventListener('click', () => { lastActive = Date.now() })
router.beforeEach((to) => {
const token = store.getToken()
if (to.meta.requiresAuth && !token) {
return { name: 'login', query: { redirect: to.fullPath } }
}
if (token && Date.now() - lastActive > IDLE_LIMIT) {
store.logout()
auditLog.warn('session_timeout', { path: to.fullPath })
return { name: 'login' }
}
})操作留痕是等保审计的重头戏。前端应该在敏感操作（删除、导出、权限变更、批量查询个人数据）触发时，向后端审计接口写入结构化日志，包含操作人、时间、对象、来源 IP 上下文等字段。注意两点：一是日志本身不得包含密码等敏感明文；二是前端日志只作为辅助证据，最终以服务端记录为准，审计报告中要说明这一层级关系，否则容易被判定为"可篡改日志"。
四、构建产物与审计证据的工程化管理
合规审计不只是运行时的事，构建环节同样有检查点。生产构建必须关闭 sourcemap，防止源码和内部逻辑泄露；vite.config.ts 中可以按环境显式控制，并在流水线中校验产物里不存在 map 文件。同时建议移除 console 输出，避免调试日志把敏感上下文带到生产环境：
// vite.config.ts
import { defineConfig } from 'vite'
export default defineConfig(({ mode }) => ({
build: {
sourcemap: false,
terserOptions: {
compress: { drop_console: mode === 'production', drop_debugger: true }
}
}
}))最后是证据留存。审计时审核方通常要求提供：数据处理清单、同意记录样本、日志留存策略、漏洞扫描报告。建议把合规检查做成 CI 中的一个独立 job，包含依赖扫描、产物检查、敏感字段 lint 三项，每次构建生成一份检查报告并按版本归档。这样当审计来临的时候，团队拿出的不是临时拼凑的截图，而是一条持续运行的合规证据链——这也正是"工程化合规"区别于"突击整改"的本质。