变量在GitCD里分好几层管理，从高到低优先级依次是：内置预定义变量、项目级变量、组级变量、流水线级变量，最后是.gitlab-ci.yml里定义的变量。这种层级设计特别实用，比如你在组级别设置通用配置，到具体项目再覆盖特定值。我团队最近就靠这个解决了多环境配置混乱的问题------在组级别设了公共的数据库地址，各项目根据环境覆盖具体连接串。
预定义变量这块特别值得关注。像CI_COMMIT_REF_SLUG这种自动生成的变量，能直接拿到分支名、提交哈希、项目路径这些关键信息。我们有个部署脚本就靠CI_ENVIRONMENT_SLUG动态生成命名空间，比手动配置省心多了。不过要注意，这些变量虽然方便，但命名规则得记牢，有时候拼写错了排查半天才发现是变量名搞混了。
创建自定义变量时有个保护选项很关键。勾选后只有受保护的分支能访问，这对生产环境配置特别重要。上次我们有个实习生误操作把生产数据库地址推到了开发分支，幸亏提前设置了保护，不然就出大事了。敏感变量比如密钥类一定要启用Mask功能，这样在流水线日志里会自动隐藏值。但得注意，已经在日志里打印过的值不能再设为Masked，这个设计是为了防止历史日志泄露。
文件类型变量可能很多人没怎么用过，其实特别适合存证书文件。我们有个项目需要TLS双向认证，直接把client.pem设为文件变量，GitLab会在容器里自动生成临时文件，路径通过变量名传递，比用base64编码再解码优雅多了。
环境变量这块有个坑得提醒下。在before_script里声明的变量，在job里是访问不到的，必须通过artifacts:reports:dotenv来传递。我们曾经折腾了两个小时才发现这个机制------当时在before_script里生成了版本号，结果后续job死活读不到值。后来改用dotenv报告就解决了。
动态变量通过API触发流水线时特别有用。我们有个监控系统检测到异常时，会调用GitLab API触发流水线并传入错误代码，这样就能针对性跑诊断脚本。不过要注意权限控制，触发token得保管好，我们吃过亏被人恶意触发了几百次流水线。
最后说说变量优先级这个最容易踩坑的地方。手动触发的流水线可以覆盖所有变量，包括受保护的。有次我手动触发生产部署，不小心覆盖了数据库密码变量，导致部署失败。后来团队定了规矩：敏感变量一律设置为只允许在受保护分支使用，手动触发时禁止修改关键配置。
实际使用中还有个技巧：变量值可以引用其他变量，比如设置DEPLOY_PATH为"/${CI_PROJECT_NAME}/dist"，这样每个项目的路径都自动生成。不过要注意避免循环引用，我们设置过一套相互依赖的变量，结果流水线直接报错卡住了。
总的来说，用好GitLab CI/CD变量就像玩拼图，得清楚每块的定位。从简单的密钥管理到复杂的多环境配置，变量机制都能hold住。关键是要建立适合自己团队的管理规范------比如我们规定所有密钥必须Mask，环境相关配置必须设置保护条件。把这些玩透了，CI/CD的灵活性和安全性都能提升一个档次。