​
在“HarmonyOS NEXT+AI大模型打造智能助手APP(仓颉版)”课程里面，有学员在开发国产中遇到了这么一个问题：

the error occurs after the macro is expanded

这里就这位学员的问题，统一做下回复，以方便其他同学参考。往期问答，可以在我主页查到。

​

问题定位

hvigor Finished :entry:default@GenerateCangjieResource. . . after 7 ms> hvigor ERROR: Failed :entry : default@compileCangjie. . .

hvigor ERROR: Tools execution failed.

error: undeclared identifier 'percent'

==> D:\CangJie\AIAssistant[entny\src\main\cangjie \util\chatline.cj:81:80:

81 l

}.padding(4) .backgroundColor(OXFFFFFF).constraintSize(maxWidth: 90.percent) .borderRadius(10)

l

note: which is expanded as followsl

l/ 73.13 /

Row() { thisView.observeComponentCreation({ elmtId，isInitialRendep => Row() { thisView.obser

l

note: the error occurs after the macro is expanded

==> D:\CanqJie\AIAssistant \entny\snc\main\cangjie\util\chatline.cj:73:1:

​

从错误信息可以看到the error occurs after the macro is expanded是指当前环境没有提供宏。

那么什么是宏呢？

在仓颉中，宏可以理解为一种特殊的函数。一般的函数在输入的值上进行计算，然后输出一个新的值，而宏的输入和输出都是程序本身。在输入一段程序后，输出一段新的程序，这段输出的程序随后用于编译和执行。为了把宏的调用和函数调用区分开来，在调用宏时需使用 @ 加上宏的名称。

从报错的位置可以知道，报错代码是这个：

Column() {

Text(title).fontSize(24).fontWeight(FontWeight.W400)

.width(100.percent).height(100.percent)

.textAlign(TextAlign.Center)

}.width(100.percent).height(48)

.alignItems(HorizontalAlign.Start).backgroundColor(0x5DE2E7)

这里的100.percent就是使用了宏。那么要宏就要导入宏。

解决方法

​

在代码中导入这个即可

import ohos.base.LengthProp

参考引用

更多仓颉学习资料，详见：

《跟老卫学HarmonyOS开发》：https://github.com/waylau/harmonyos-tutorial


《跟老卫学仓颉编程语言开发》：https://github.com/waylau/cangjie-programming-language-tutorial


“HarmonyOS NEXT+AI大模型打造智能助手APP(仓颉版)”：https://coding.imooc.com/class/927.html


《仓颉编程从入门到实践》（北京大学出版社）：https://waylau.com/about-cangjie-programming-language-tutorial-book/

​
​

编者按

在医药零售行业，传统的“进销存”模式正面临严峻挑战，数字化转型已成必答题。对于拥有8600多家门店、自营会员超 3500 万的上市企业漱玉平民而言，如何支撑海量数据的实时分析？如何应对大促期间数倍于平时的流量洪峰？

本文梳理了漱玉平民移动互联研发负责人张新新的实战分享。他详细复盘了漱玉平民如何从传统 MySQL 架构向平凯数据库（TiDB企业版） + Kubernetes (K8s) 云原生架构演进，成功构建起支撑亿级会员 CRM 及药店数字助理（PDA）的核心系统，实现了从“T+1”报表到实时精准营销的跨越。

漱玉平民移动互联研发负责人 张新新

一、 转型背景：当传统架构遇上“万店规模”

作为长江以北医药零售领域的领军企业，漱玉平民大药房于 2021 年上市后，迅速按下了数字化转型的快进键。截至目前，漱玉平民拥有 8600 多家门店（含直营、加盟及托管），自营会员数超过 3,500 万，全生态用户日活超 2 万。

随着业务版图从山东向东北、福建、河南等地扩张，传统的商业模式和技术架构遭遇了瓶颈：

• 业务模式转变： 竞争日益激烈，单纯靠赚取差价的模式难以为继，企业急需通过数字化手段挖掘客户价值，从简单的药品订单转向全生命周期的健康服务。
• 数据规模爆发： 会员中心（CRM）不仅要管理千万级会员，还涉及积分（作为负债管理，要求强一致性）、订单明细、优惠券等数据。单表数据量迅速突破 10 亿级。
• 实时性要求极高： 业务部门需要基于 1,700 多个标签进行复杂的“漏斗查询”和精准营销，传统数据库无法满足实时响应需求。

二、 痛点分析：MySQL 分库分表的“不可承受之重”

在数字化中心成立初期，核心系统底层使用的是自建 MySQL。面对海量数据，团队曾尝试通过中间件（如 MyCat、Sharding）进行分库分表优化，但很快触及了天花板：

1. 查询性能瓶颈： 当进行复杂的会员分析（如流失模型、慢病复购、组合标签筛选）时，MySQL 难以支撑跨库的复杂关联查询，往往只能做到“T+1”的数据分析，无法支持实时营销。
2. 运维研发成本高昂： 分库分表方案将大量的数据路由和运维复杂性抛给了研发和运维团队。作为甲方企业，维护一套复杂的中间件逻辑，投入产出比极低。
3. 扩展性受限： 企业的扩张往往通过并购进行，数据增长是非线性的。每并购一家连锁药店（可能涉及千万级会员），就需要重新规划分片，传统架构难以应对这种垂直式的数据激增。

三、 选型决策：拥抱分布式与云原生 (平凯数据库 + K8s)

基于 CAP 理论和业务需求，漱玉平民决定引入分布式数据库以降低运维复杂度，并最终锁定了平凯数据库，结合 Kubernetes (K8s) 构建混合云架构。

核心选型逻辑：

• 水平扩展能力： 必须具备弹性伸缩能力，以应对“5·18”大促等活动期间高达 7,000-8,000 万 的日销售额峰值（平时约 2,000 万）。
• MySQL 高兼容性： 降低迁移成本。实战中，核心 CRM 系统仅用不到 1 小时便完成了从 MySQL 到 TiDB 的切换，且无需回滚。
• HTAP 混合负载： 同时满足交易（TP）的高并发写入和分析（AP）的实时查询需求。

四、 核心场景实践与收益

亿级会员 CRM：从 T+1 到“实时精准营销”

CRM 系统是本次重构的重中之重。通过平凯数据库的列存分析能力（TiFlash），漱玉平民实现了真正的实时标签检索。

• 场景： 业务人员需要拼接几千个条件，筛选出“即将流失”、“慢病需复购”或“高价值”会员。
• 改变： 以前只能依赖 T-1 的离线数据；现在可以秒级响应，实时触发优惠券推送、用药提醒和复购激励，极大地激活了存量会员价值。

药店数字助理（PDA）：赋能一线店员

PDA 是店员工作的统一入口，承载了进销存、收货强监管（电子签章）、业绩查询等核心功能。

• 技术支撑： 基于 K8s 的微服务架构与平凯数据库的结合，保证了应用的高可用。
• 业务价值： 在应对医保双面账、药品监管码全链路追踪等复杂业务逻辑时，系统保持了极高的稳定性，支撑了日均万级的 QPS。

运维体系：AI 赋能与全链路追踪

研发团队并不止步于数据库的替换，还构建了完善的运维监控体系：

• 可观测性： 利用 Dashboard 和全链路追踪（Trace ID），将数据库视为“白盒”，精准定位慢 SQL 和 API 响应延迟。
• AIOps 探索： 引入 AI 运维机器人，基于指标预测潜在故障；在开发阶段引入 CodeReview AI 工具，提前规避性能低下的 SQL 代码上线。

五、 未来展望

目前，漱玉平民已将 CRM、数据资源中心等核心业务平滑迁移至平凯数据库，并构建了基于 K8s 的混合云底座。

张新新表示，未来的技术规划将聚焦于三个方向：

1. 深化智能化营销 (MA)：医药零售具有极强的季节性和突发性（如流感季）。未来，漱玉平民计划进一步挖掘平凯数据库的实时分析能力，结合 AI 算法，从“看库存”向“预测库存”进阶。系统将能够根据区域销售趋势，自动进行智能补货和调拨，在降低周转天数的同时，确保急需药品的现货率。 这套更智能的一体化营销系统，基于 K8s 和平凯数据库进一步隔离资源，确保高并发下的营销计算不影响核心交易。
2. 扩大分布式应用范围： 将更多历史遗留系统逐步迁移至平凯数据库，统一技术栈，降低维护成本。
3. 强化业务连续性 (BCP)： 持续优化双机房集群架构，确保在单机房故障时核心业务不受影响，守护每一笔交易。

对于零售企业而言，技术的价值在于业务连续性和数据准确性。平凯数据库+ K8s 的组合，不仅解决了海量数据的存储与计算瓶颈，更重要的是，它将研发团队从繁琐的分库分表维护中解放出来，更专注于业务创新和客户价值的实现。

在日常工作中，你是否遇到过这样的困扰：打开一个包含大量数据的报表，向下滚动查看数据时，表头也跟着滚动消失了，结果看着看着就不知道这列数据代表什么意思了；向左滚动时，关键的第一列信息也看不到了，只能来回滚动确认，效率低下，体验极差。

积木报表（jimureport）  的冻结单元格功能，完美解决了这个痛点！让表头和关键列 "站住不动"，无论数据有多少，都能轻松查看，再也不用担心滚动时迷失方向了。

积木报表

积木报表，是一款免费的数据可视化报表，含报表、打印、大屏和仪表盘，像搭建积木一样完全在线设计！功能涵盖：复杂报表、打印设计、图表报表、门户设计、大屏设计等！ 分两大模块：JimuReport 侧重传统复杂报表和打印、 JimuBI 侧重数据大屏和仪表盘可视化设计！

代码下载

• https://github.com/jeecgboot/JimuReport

技术文档

• 快速集成 ：https://help.jimureport.com/quick.html
• 官方网站： http://jimureport.com
• 报表示例： http://jimureport.com/reportDemo
• 在线体验： http://jimureport.com/login

解决方案：积木报表冻结功能，让表头 "站住不动"

1. 固定头部：向下滚动，表头始终可见

当数据行数较多，需要向下滚动查看时，固定头部功能让表头始终停留在顶部，无论滚动到哪里，都能清楚地知道每一列数据的含义。

适用场景：

• 数据行数较多的报表
• 需要频繁查看列标题的场景
• 多维度数据分析报表

配置简单：  只需在积木报表设计器中勾选 "固定头部" 选项，即可实现表头冻结，操作简单，效果立竿见影。

2. 固定左侧：向左滚动，关键列始终可见

当列数较多，需要向左滚动查看时，固定左侧功能让第一列或前几列关键信息始终停留在左侧，无论滚动到哪里，都能看到关键标识信息。

适用场景：

• 列数较多的宽表
• 第一列包含关键标识信息（如姓名、ID、日期等）
• 需要横向对比多列数据的场景

灵活配置：  可以灵活选择需要固定的列数，根据实际业务需求进行配置，让关键信息始终可见。

3. 同时固定头部和左侧：全方位锁定，数据查看更轻松

对于数据量大、列数多的复杂报表，可以同时固定头部和左侧，实现 "十字锁定" 效果。这样无论向哪个方向滚动，都能同时看到表头和关键列，数据查看更加直观高效。

适用场景：

• 大型数据报表
• 多维度复杂数据分析
• 需要频繁交叉查看行列数据的场景

完美体验：  表头和关键列不随浏览器滚动而滚动，始终保持在可见区域，让数据查看变得轻松自如。

结语

数据查看效率直接影响工作效率和决策质量。积木报表（jimureport）  的冻结单元格功能，用简单的方式解决了复杂的问题，让数据查看变得轻松高效。无论是固定头部、固定左侧，还是同时固定，都能根据实际需求灵活配置，让表头 "站住不动"，数据查看更轻松。

如果你也经常被滚动时标题丢失的问题困扰，不妨试试 积木报表（jimureport）  的冻结功能，相信会给你带来全新的数据查看体验！

积木报表（jimureport）  - 让数据报表设计更简单，让数据查看更高效！

引言

近日，PostgreSQL 全球顶级开发者盛会 PGConf.dev 2026 已公开议程​。

IvorySQL 开源数据库社区传来重磅喜讯：社区成员 Grant Zhou 与厉超提交的技术议题双双入选！

作为中国本土开源数据库社区在国际舞台的重要发声，这不仅是对两位开发者个人技术实力的认可，更标志着 IvorySQL 在推动中国技术力量融入 PostgreSQL 全球核心社区、从“参与者”向“贡献者”转变的征程上，迈出了坚实的一步。

议题速览：从宏观连接到微观实践

在今年的温哥华盛会上，IvorySQL 的两位专家将分别从生态连接与内核开发成长两个维度，分享来自中国社区的实践与思考。

🎙 演讲人：Grant Zhou

• 议题： 《失落的环节：将数万名中国用户与 PostgreSQL 核心连接起来》 (​The Missing Link: Connecting Tens of Thousands of Chinese Users to the PostgreSQL Core​)

• 核心看点：

  • 打破“沉默的大多数”： 探讨中国庞大的企业级用户群（金融、政府、制造业）与全球开发社区之间的脱节现状。
  • 硬核实战反馈： 分享在物联网高频数据写入、大规模分区及 Oracle 到 PostgreSQL 迁移中的真实痛点。
  • IvorySQL 的使命： 阐述为何我们需要构建 IvorySQL 等下游项目来填补原版扩展性的空白，并探讨全球社区如何更好地集成这些企业级用例反馈。

🎙 演讲人：厉超

• 议题： 《快速学习 PostgreSQL 内核开发：新手的经验与教训》 (​Learning PostgreSQL Hacking Fast: Lessons and Mistakes from a Newcomer​)

• 核心看点：

  • 快速进阶指南： 分享如何在短短数月内从新人成长为深度参与 150+ 次提交（Commit）的贡献者。
  • 避坑指南： 坦诚分享在代码阅读、补丁评审及社区交流中走过的弯路和技术误区。
  • 实战工具箱： 揭秘加速学习的工具流（调试、测试、邮件列表处理），为全球开发者提供一份可复制的“内核黑客成长手册”。

社区担当：做中国 PG 力量的“架桥人”

长期以来，中国的 PostgreSQL 生态呈现出“内热外冷”的现象：国内应用极广，但在国际核心圈层的话语权仍有提升空间。

作为致力于“兼容 Oracle 生态”的开源数据库社区，IvorySQL 始终坚持“源于 PostgreSQL，回馈 PostgreSQL”。我们深知，真正的开源精神不仅仅是利用现有的代码，更是在全球主流社区中贡献中国场景下的创新。

IvorySQL 是瀚高基础软件股份有限公司于 2021 年发起并主导研发的开源数据库项目。项目基于 PostgreSQL 内核构建，核心目标是解决企业从 Oracle 向 PostgreSQL 迁移过程中面临的兼容性、成本及生态适配等关键问题。与此同时，瀚高股份始终积极参与 PostgreSQL 全球及国内社区建设，持续投入社区贡献，全力推动 PostgreSQL 生态的繁荣与发展。

• Grant Zhou 正在通过 IvorySQL 搭建起企业与核心社区的桥梁，让“沉默”的中国需求被世界听到。
• 厉超 作为 IvorySQL 社区涌现出的新锐力量，在 PG 18 版本的代码贡献中表现优异，成为了中国年轻一代开发者参与国际开源协作的典范。

结语：五月，温哥华见！

2026 年 5 月 19 日，加拿大温哥华。

当 IvorySQL 的开发者站上 PGConf.dev 的讲台，分享来自中国真实场景的性能挑战与成长经验时，我们正向世界发出一个清晰的信号：中国开发者不仅是代码的使用者，更是 PostgreSQL 生态进化的重要推动者。

让我们期待 Grant Zhou 与厉超在温哥华的精彩表现，也欢迎更多热爱开源的小伙伴加入 IvorySQL 社区，共同建设更强大的 PostgreSQL 生态！

👉HOW 2026 议题招募中

2026 年 4 月 27-28 日，由 IvorySQL 社区联合 PGEU（欧洲 PG 社区）、PGAsia（亚洲 PG 社区）共同打造的 HOW 2026（IvorySQL & PostgreSQL 技术峰会） 将再度落地济南。届时，PostgreSQL 联合创始人 Bruce Momjian 等顶级大师将亲临现场。

自开启征集以来，HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度，我们诚邀您提交前沿技术实践与洞见，共同打造高质量议题内容。

投递链接：👉https://jsj.top/f/uebqBc

干市政工程的,最怕什么?

不是工期紧,不是预算少,是心里没底。项目一铺开,工点几十个,战线几十公里,专业七八个,你一天跑断腿也盯不全。现场报上来的数据,你心里得打个折;采购说的价格,你得翻三天聊天记录才能对上。等到项目结束一算账,明明干得热火朝天,利润却薄得像刀片。钱去哪了?不知道。问题出在哪?说不清。

这种失控感,比任何难题都磨人。2026年了,还在靠Excel和微信群硬扛,扛到最后,扛走的都是你的利润。今天咱们就聊聊,那些真正懂行的工程人,都在用什么东西把“点多线长面广”这个死局,一点点掰回来的。

别让失控感,把你的利润吃干抹净

市政项目怎么死的?是被失控感一点一点拖死的。你没法“关门干活”——拆迁、管线、市民出行,随便一个外力就能让计划作废。更要命的是,所有信息到你手里都是滞后的二手货:进度得打折听,价格得翻聊天记录对。等完工算账才发现超了,但超在哪?复盘不出,因为没有数据。

那些总能赚钱的项目经理,强在能把每一个工点、每一段工期都攥在手里。问题刚冒头就被掐住。过去这靠天赋,但在2026年,靠的是一套能打通所有信息孤岛的数字化工具。

红圈工程项目管理系统——给工地装上“数字神经系统”

首先要聊的这家,不是因为它名气大,而是因为它真正懂工程人每天在为什么事烦心。红圈,是和创(北京)科技股份有限公司旗下专为建筑工程行业打造的工程项目管理平台。这家公司2009年成立,是国内最早涉足SaaS领域的企业之一,十几年一直死磕一件事:用技术帮工程企业把项目管明白。为了满足不同企业、不同项目的个性化需求,他们从2015年开始自研PaaS平台,有了这个底座,系统既能快速迭代,又能灵活适配,像搭积木一样配置出适合市政、房建、装饰、机电、新能源等不同业务场景的功能模块。到今天,已经有4000多家建筑工程企业用上了红圈系统。

市政工程那种“点多线长面广”的特性,恰恰是红圈最擅长对付的。道路、管网、桥梁、隧道、给排水、园林、电力……这些细分领域红圈都覆盖了。它不是一个只盯着财务或者资料的软件,而是一个以提升企业经营结果为目的的信息化平台,核心就是把围绕项目的所有业务流程都标准化、透明化。从投标、立项,到施工、结算,全生命周期管起来,让执行层没法偷懒,让管理层心里有底。

那是具体怎么帮你把失控感一点点收回来?红圈这两年把人工智能深度融进了产品,推出了红圈AI系列产品,每一个都打在工程管理的痛点上。

先说最让老板头疼的信息汇总。项目一多,每个工地报上来的数据七零八落,你想知道全局,得等下面人熬夜做PPT。红圈AI系列产品中的BOSS助理Agent就是冲着这个来的。你随时可以问它:“某某路桥项目这个月的产值多少?回款到了哪一步?”它能在几秒钟内抓取所有相关数据,生成清晰的经营汇报。再也不用追着各部门要报表,更不用怕数据对不上。

光看数据还不够,关键是要看懂数据背后的风险。红圈项目360°AI解读能一键整合项目的资金、成本、合同、付款等所有经营指,生成一张项目全景作战图。它还能调用行业专家经验,给每个项目打分评级,告诉你毛利率为什么掉下来,主要风险点在哪,甚至给出具体应对建议。以前经营分析会上大家花大量时间核对数据,现在会前就能把风险摸清楚,决策效率提升不止一倍。

市政项目材料种类多、单据多,混凝土票、机打送货单、手写确认单,每天收一堆。材料员得一张张录入系统,录错一个数字,后面的成本全乱套。红圈AI录单助手就是来解放他们的。拿手机对着单据拍张照,大模型自动识别关键字段,然后自动匹配到对应的合同和项目上,几秒钟完成录入,准确率极高。原来半天的工作量,现在十分钟搞定,数据直接归集到项目成本里,后期追溯清清楚楚。

供应商管理也是个大麻烦。市政项目分包多、采购杂,新进来的供应商靠不靠谱,光看资质和报价根本不够。红圈采购助理Agent能帮你给供应商做AI风险评级,能够自动抓取工商、司法、税务等公开数据,从六个维度给供应商打分,3秒出结果,40秒出一份完整的风险评估报告。哪家有法律诉讼?哪家被列了经营异常?哪家资金链可能出问题?一目了然。有了这个,再也不用凭感觉选供应商,入库风险大大降低。

除了管外面的事,红圈还能帮企业把内部的经验和知识沉淀下来。很多工程公司,老人一走,经验就断了,新员工上手慢,同样的坑踩了又踩。红圈AI企业知识库把分散在个人手里、各个文件夹里的历史投标方案、施工组织设计、诉讼案例、公司制度全部整合起来。员工想问什么,直接打字提问,比如“哈尔滨出差住宿标准是多少?”3秒内给你精准答案。新人培训周期大幅缩短,公司的经验真正变成了可以随时调用的资产。

至于合同审核这种高风险、低效率的活儿,红圈AI业务助手能自动识别合同里的风险条款,提醒你注意,避免签完才发现掉坑里。还有用印管理,红圈AI智能印控,把实体印章锁进智能设备里,每次盖章都要经过线上审批、指纹验证,文件内容自动比对,用印过程全程拍照录像留痕。那些私盖空白合同、篡改条款、事后不认账的风险,基本上被堵死了。

有了它,分散的工点、延绵的战线、交错的专业,不再是失控的黑洞,而是被一条条数据线串联起来,清清楚楚呈现在你面前。你不再是到处救火的消防员,而是运筹帷幄的指挥官。

Buildertrend——中小项目的“家装级”精细化管理

很多中小市政公司老板觉得上系统门槛太高,习惯用Excel凑合,结果项目一多,预算超支、工期延误、客户投诉接踵而至,根本顾不过来。

Buildertrend正是专为这类中小型项目设计的轻量级管理工具,尤其适合注重客户体验的改造、维修类市政项目。它将客户管理、预算控制、合同签署与施工进度可视化集于一体,从报价到完工全程透明。现场人员用语音转文字即可录入施工日志;与QuickBooks等财务软件深度集成,资金流水自动同步,省去反复对账的麻烦。

Deltek Open Plan——超级工程的“排程专家”

如果你的项目涉及全市地铁网络、上百亿投资的大型综合管廊,其进度管理远超一般工程复杂度,那么Deltek Open Plan值得关注。它是一款面向中大型项目群的专业排程工具,在高级排程、关键路径分析和多项目统筹方面表现突出。

Open Plan能将资源共享、多项目并行等复杂场景纳入统一控制框架,尤其适合PMO统筹子项目、严格分配资源的治理场景。当多项目争夺关键设备或人员时,系统能清晰展示冲突并辅助排期调整。

AutoCAD Civil 3D 2026——让设计院和施工队“说同一种话”

AutoCAD Civil 3D 2026旨在解决市政工程中设计与施工脱节、频繁返工的痛点。它不仅是画图工具,更是一个三维设计平台,其创建的道路、管网模型本身就包含数据,能直接出图、精准算量,并应用于施工阶段。

2026版协同能力大幅提升,模型一改,各方同步,避免了信息差。现场人员还可用手机AR功能将模型叠加于实地,实现精准放样。它让设计与施工团队在同一张图上协作,有效减少返工。

Bentley OpenRoads Designer——让设计和施工“无缝衔接”

市政工程中设计与施工脱节的问题,常常让项目返工不断。Bentley OpenRoads Designer正是一款专为复杂基础设施设计打造的三维平台,在道路、桥梁、隧道等线性工程领域表现突出。

OpenRoads的核心优势在于强大的实景建模能力,可以直接将无人机航测、激光雷达数据导入设计环境,大幅减少现场勘测与设计之间的信息差。对于穿越复杂地形的市政道路或管线项目,它的螺旋过渡、超高处理等道路几何设计流程比传统工具更高效。

选对工具,把失控的项目一个一个拉回来

2026年了,市政工程早就不是靠两条腿、一张嘴就能管好的年代了。面对“点多线长面广”这道难题,我们只有一件事能做——用工具,把失控的每一个点、每一段线、每一个面,重新拉回到自己手里。

别再用Excel和微信群硬扛了。那个扛法,扛到最后,扛走的都是你的利润。

今天聊的这几款,各有各的脾气,各有各的战场。红圈适合那些想要全方位掌控项目、用AI赋能管理的企业;斗栱云是中小企业的性价比之选;P6是超级工程的进度神器;Civil 3D解决设计与施工的脱节;明源云是甲方全局管控的首选。

对号入座,找到最适合你的那把钥匙,让每个项目,真正尽在掌握。

全球数字化浪潮愈演愈烈，大有席卷全球之势。对此，为网站部署数字证书，启用HTTPS安全加密技术，依然成为企业建立线上安全营销环境与信任体系的基础动作，其醒目的安全锁标识与https前缀，是网站安全的象征，也是获取用户信任的基石。然而，拥有证书并非完全等同于拥有相应的安全防护。从SSL证书部署配置，到日常管理，任何一个环节出现纰漏，都可能导致证书的安全加密形同虚设，成为网络黑客攻击的突破口。JoySSL市场调研专家指出，综合目前国内绝大多数网络安全事故发生的诱因来看，绝大多数事件的根源并非源于数字证书的加密技术，而是企业在部署和配置环节存在严重失误，导致未能正确利用SSL证书加密功能，从而给网络威胁提供了有利条件。唯有正确、规范的配置管理数字证书，才能彻底发挥其作为网络安全防护产品应有的作用，将潜在的网络风险转化为信任资产。

弱加密与私钥管理不当 为攻击者创造便利条件

证书部署后若采用默认TLS配置，会导致仍支持存在漏洞的旧版协议，加密连接可被强制降级，从而信息被轻松窃取与解密。私钥管理不当导致泄露，会被攻击者利用，解密来往通信数据，伪造服务器身份进行中间人攻击，危害将持续至证书到期。

启用TLS1.2以上版本，选择支持前向保密的强加密套件，是确保信息加密的技术前提，是封堵漏洞的关键；而采用硬件安全模块等方式正确管理私钥，可确保核心资产不受影响。

证书过期阻断业务 内容混合让安全锁形同虚设

一旦SSL证书因续费不及时，或缺乏有效监测机制导致过期，会直接中断所有安全服务，导致排名下降，用户信任崩塌，运维压力与成本上升，品牌信誉受损。混合内容加载则进一步降低安全评级，警告用户甚至直接拦截，HTTP加载的资源也可能遭到中间人随意篡改。

自动化证书监控与续期机制，对证书过期危机至关重要，可有效杜绝人为遗忘引发的一系列严重后果，保障业务与服务的连贯性；而实现全站HTTPS则可有效修复混合内容问题，构建纯净的加密环境。

配置SSL证书出现匹配与完整问题 引发信任危机

证书与域名不匹配，会导致浏览器弹出证书错误警示，使用户访问受阻，导致潜在客户对网站的专业性产生质疑。同时，在部署SSL证书时一旦不能完整拼接，用户将无法正常访问网站，潜在客户极速流失。

正确选择数字证书类型，可有效匹配域名，避免因覆盖不完整导致信任链条中断；而严格按照服务器类型配置证书链，可确保证书在所有客户端都能被正确验证，维系客户信任。

正确管理与配置数字证书 高效发挥安全锁功用

SSL证书如同一把精密的安全门锁，仅仅拥有它，并不能体现安全价值。唯有通过正确的安装，合理的配置与持续的监控维护，才能让门锁的功能得到全面发挥，创造便利的同时也享受安全保障。JoySSL市场经理认为，投资数字证书不应局限于购买行为，更需要覆盖至证书整个生命周期内，通过规范化管理，充分展现SSL证书的安全能力，让每一道加密都坚不可摧，让每一次访问都始于信任。

本文围绕 Jira 替代软件 的核心诉求，测评对比 ONES、Tower、Azure DevOps、GitLab、YouTrack、GitHub Projects、Linear、monday dev，从流程、进度、协作、效能、开放拓展、端到端闭环、知识沉淀与质量测试治理等维度给出可执行的选型建议，帮助管理者降低替换风险、提升落地成功率。

在我参与过的替换项目里，真正推动组织寻找 Jira 替代软件 的，往往是三类结构性变化：

• 规模变化：团队数量上升、产品线增多、外包/合作团队加入后，“靠自觉更新状态”的方式会迅速失效。
• 复杂度变化：从单一 Scrum 团队走向“多团队并行 + 平台/业务耦合”，依赖与资源冲突成为常态，靠看板很难提前预警。
• 治理诉求变化：合规审计、质量体系、交付可靠性要求提升，组织需要“证据链”和“追溯链”，而不是“看起来很忙的状态流转”。

选型框架：评估 Jira 替代软件的 8 个维度

我建议把评估框架拆成三层：先看约束，再看闭环，后看体验。这样更接近管理决策逻辑，也更利于 PMO 组织评审会落地。

1. 三层选型法：先约束、再闭环、后体验

• 第一层：组织约束（先排除）：部署形态（SaaS/私有化）、数据安全与审计、账号体系、权限模型、采购合规。这是“能不能用”的底线。
• 第二层：端到端闭环（决定上限）：需求→开发→测试→发布→反馈能否形成追溯链？如果交付可靠性是竞争力，这一层权重大于“界面是否好看”。
• 第三层：协作体验与效率（决定落地速度）：易用性、通知、跨职能协作、自动化与开放接口，决定团队“愿不愿意用、能不能坚持用”。

结论：治理诉求越强（合规/质量/审计），越要优先选择“闭环与治理能力强”的 Jira 替代软件；团队越小越敏捷，越要优先选择“体验与效率强”的替代工具。

2. 八个维度：让“评估可复制”，避免平均用力

1. 工作项模型与流程：Issue/需求/缺陷/任务层级是否清晰？工作流可配置且可治理？
2. 规划与路线图：是否支持 Epic/Feature/里程碑、跨项目视图、依赖与时间线（roadmap/甘特）？
3. 进度与交付治理：冲刺、燃尽、WIP、关键路径、风险与资源冲突能否提前暴露？
4. 协作体验：评论、@、通知、跨部门协作、移动端与沟通工具集成是否顺畅？
5. 端到端闭环：需求→代码→测试→发布→反馈的追溯链是否可建立？
6. 质量与测试治理：测试计划/用例/执行/缺陷/回归/覆盖的治理能力如何？
7. 效能度量与改进：是否支持稳定口径的仪表盘、趋势、分层改进闭环？
8. 开放拓展与合规：API/Webhook、生态集成、权限审计、数据安全与部署弹性。

3. Jira 常见能力映射：替代时你到底在替代什么

为了更贴近检索意图，这里把 Jira 常见能力拆成“可被替代的能力块”：

• Issue/工作项管理：任务、缺陷、需求、子任务层级
• Workflow/流程与权限：状态流、审批、字段口径、权限边界
• Agile/敏捷节奏：Backlog、Sprint、看板、燃尽、WIP
• Roadmap/跨团队计划：里程碑、依赖、时间线、组合视图
• Reporting/度量：报表、仪表盘、趋势与口径稳定性
• Integration/开放生态：代码仓库、CI/CD、IM、知识库、工单

结论：如果你的 Jira 主要被当成“协作推进中心”，替代重点在体验与跨职能；如果 Jira 被当成“研发治理中心”，替代重点在闭环、测试治理与口径稳定。

本章要点

• 选型优先级：约束（能用）→闭环（上限）→体验（落地速度）。
• 用“Jira 能力块映射”做对比，评审会更容易达成共识。
• 真正的替代不是 UI 相似，而是 治理能力与追溯链能力 能否承接。

工具速览：8 款 Jira 替代软件的定位与替代强度

这里的“替代强度”不是绝对好坏，而是对 Jira 能力块（流程、计划、协作、治理、闭环）的覆盖程度，以及对组织治理的支撑上限。

本章要点

• ONES / Azure DevOps / GitLab 更偏“治理与闭环型”Jira 替代软件。
• Tower / monday dev 更偏“协作推进与跨职能对齐型”。
• Linear / GitHub Projects 更偏“轻量高效率、贴近研发日常型”。
• YouTrack 介于两者之间，优势在工作流弹性与工程团队适配。

四、分层深评：8 款 Jira 替代软件测评对比

1）ONES：组织级研发治理底座的 Jira 替代软件

很多组织在替换 Jira 时，会忽略一个事实：Jira 解决的是“记录与流转”，而组织需要的往往是“治理与闭环”。ONES 的价值更接近后者——它更像一个可承接组织方法论、支持规模化治理的研发管理底座。

ONES 核心信息

定位：企业级端到端研发管理平台（研发项目管理 + 质量测试治理 + 知识沉淀 + 度量改进）

Jira 替代能力映射：

• Issue/工作项：可承接（需求/任务/缺陷层级）
• Workflow/权限：可承接（流程、字段口径、权限边界）
• Agile/敏捷：可承接（Backlog、迭代节奏、看板/燃尽）
• Roadmap/组合：偏强（多项目视角、里程碑与治理）
• Reporting/度量：偏强（口径治理与持续改进导向）
• Integration/生态：可承接（开放拓展与平台化）

适用场景：多团队并行、跨项目依赖明显、希望端到端闭环与统一治理的组织

一句话结论：把 Jira 从“项目工具”升级为“组织能力底座”的团队，通常更容易发挥 ONES 的价值。

优势亮点：

ONES 的优势在于更容易把“端到端闭环”设计成一个系统工程：

• 知识沉淀：需求背景、决策记录、技术方案、复盘结论与工作项关联，降低新人上手成本与重复决策。
• 质量测试治理：测试活动与需求、缺陷、版本形成追溯链，质量不再只是测试团队责任，而是组织交付约束。
• 效能改进：当你拥有稳定口径的数据，改进就不会变成观点之争，而能回到事实与趋势。

这正是我判断某个工具是否是合格的 Jira 替代软件 的分水岭：它能否支撑组织把“流程—交付—质量—度量”连成闭环，而不是做成局部最优。

局限与使用体验

• 前期设计成本不可回避：越强调闭环与治理，越需要把流程与口径讲清楚，否则会出现“工具很强，但用法各异”的二次混乱。
• 需要组织配套机制：例行评审、里程碑检查、质量门禁、复盘机制。没有这些，任何平台最终都会退化为“更贵的任务列表”。

2）Tower：更轻量的 Jira 替代软件

Tower 的典型优势是：让“计划—执行—推进—对齐”变得更轻、更直观。很多组织实际把 Jira 用成跨职能协作中枢，而不是纯研发工具；此时 Tower 往往能更快提升体验与协作效率。

Tower 核心信息

定位：团队协作与项目推进工具（多视图进度管理）

Jira 替代能力映射：

• Issue/工作项：可承接（任务协作为主）
• Workflow/权限：部分承接（适度流程）
• Agile/敏捷：部分承接（节奏管理可做）
• Roadmap/组合：中等（更偏推进视图）
• Reporting/度量：中等（更多依赖机制）
• Integration/生态：需按场景评估

适用场景：协作密集、跨部门推进频繁、希望降低工具学习与维护成本

一句话结论：更像“推进中枢”的 Jira 替代方案，而不是“研发治理中枢”。

优势亮点：

替换 Jira 往往不是技术难，而是变更管理难。工具如果让成员感觉“更复杂、更痛苦”，迁移就会失败。Tower 的优势在于上手快、推广快、跨职能参与门槛低——这对很多组织是关键胜负手。

局限与使用体验：

• 数据一致性更依赖团队纪律：需要例行机制（周计划/里程碑检查/风险登记）。
• 工程闭环与质量治理要配套：否则会出现“推进很顺，但质量与证据链缺失”。

3）Azure DevOps：工程治理型 Jira 替代软件

如果你的组织对工程化治理要求高——例如标准化流程、审计追溯、测试体系、发布证据链——Azure DevOps 往往更贴近“体系化替代”。

Azure DevOps 核心信息

定位：DevOps 套件（计划/开发/测试/交付协同）

Jira 替代能力映射：

• Issue/工作项：强
• Workflow/权限：强
• Agile/敏捷：强
• Roadmap/组合：中强（取决于组织用法）
• Reporting/度量：中强（需要口径治理）
• Integration/生态：偏强（尤其微软生态）

适用场景：微软技术栈、中大型研发组织、质量体系要求高

一句话结论：工程治理型 Jira 替代软件，适合“要证据链、要可审计”的组织。

局限与使用体验：

• 需要明确平台与流程负责人，否则容易出现“功能很多但团队只用浅层”。
• 对非研发角色不一定最友好，需要模板化与培训支持。

4）GitLab：计划与交付型 Jira 替代软件

GitLab 的典型优势是把计划、代码、流水线、交付与度量拉到同一平台，使“状态更新”更可能从手工变成自动联动。对追求交付效率与可靠性的组织，这种整合价值往往高于“单点功能更强”。

GitLab 核心信息

定位：一体化 DevSecOps 平台（计划到交付同平台）

Jira 替代能力映射：

• Issue/工作项：强
• Workflow/权限：中强（看组织需求）
• Agile/敏捷：中强
• Roadmap/组合：强
• Reporting/度量：中强（需治理）
• Integration/生态：强（平台内整合优势明显）

适用场景：希望减少系统割裂、强调从需求到发布追溯的组织

一句话结论：适合把“计划—开发—交付”做强整合的 Jira 替代方案。

局限与使用体验：

• 更偏工程团队主导，产品与业务参与时可能需要更友好的协作入口与模板化流程。
• 需要明确边界：哪些工作留在 GitLab，哪些留在知识/产品系统，避免“所有东西都塞进一个平台”。

5）YouTrack：流程与工作流自动化 Jira 替代软件

YouTrack 的特点在于：既支持 Scrum、Kanban 与混合方法，也强调工作流自动化与可定制性。对流程有明确“组织个性”的团队，这是一个折中选择。

YouTrack 核心信息

定位：Issue 跟踪 + 敏捷面板 + 工作流自动化（工程团队适配）

Jira 替代能力映射：

• Issue/工作项：中强
• Workflow/权限：中强（弹性大）
• Agile/敏捷：强
• Roadmap/组合：中等（看治理与配置）
• Reporting/度量：中等（更依赖口径）
• Integration/生态：中等（按场景）

适用场景：工程团队主导、需要灵活流程、希望“流程可编排”

一句话结论：灵活是优势，也是治理挑战；成功高度依赖 Owner 机制。

6）GitHub Projects：开发者适用的 Jira 替代软件之一

对以 GitHub 为研发中心的团队，GitHub Projects 的优势非常现实：减少工具切换，计划与执行靠近代码与 PR。

GitHub Projects 核心信息

定位：围绕 GitHub Issues/PR 的轻量计划与跟踪

Jira 替代能力映射：

• Issue/工作项：中强（围绕 Issues）
• Workflow/权限：中等（偏轻）
• Agile/敏捷：中等（够用但不重）
• Roadmap/组合：中等
• Reporting/度量：偏弱（需外部补齐）
• Integration/生态：强（在 GitHub 生态内）

适用场景：中小团队、开源/内源、研发协作为中心

一句话结论：替代“研发任务协同”容易，替代“组织治理”较难。

7）Linear：高节奏团队适用的 Jira 替代软件

Linear 的价值在于做减法：减少配置噪音，让注意力回到交付与节奏上。对迭代快、团队小而精的组织，常有明显体感提升。

Linear 核心信息

定位：现代产品研发协作系统（轻量高效、节奏清晰）

Jira 替代能力映射：

• Issue/工作项：中强
• Workflow/权限：中等（偏简）
• Agile/敏捷：强（节奏优势）
• Roadmap/组合：中等（看规模）
• Reporting/度量：中等（需治理）
• Integration/生态：中强（自动化友好）

适用场景：中小团队、高迭代节奏、追求效率与低负担

一句话结论：适合“速度优先”的团队；强治理诉求组织需谨慎评估边界。

8）monday dev：跨职能可视化 Jira 替代软件

monday dev 的优势是“让不同角色都看得懂”。当产品、设计、运营、交付等角色参与度高时，沟通成本往往成为主要瓶颈。

monday dev 核心信息

定位：面向产品开发的协作与节奏管理套件（跨职能可视化强）

Jira 替代能力映射：

• Issue/工作项：中
• Workflow/权限：中等（需评估复杂度）
• Agile/敏捷：中强（节奏与可视化）
• Roadmap/组合：中等（偏对齐）
• Reporting/度量：中等
• Integration/生态：中等（按场景）

适用场景：跨职能协作密集、希望提升计划透明与沟通效率

一句话结论：更像“对齐与推进型”Jira 替代方案，工程治理深度需验证。

趋势预测：从“换 Jira”到“建设组织数字化能力”

未来两年我更确认的方向是：研发管理工具正在从“记工系统”走向“治理系统”。组织要的不是把工作记录下来，而是把“怎么做、做到什么程度、如何持续改进”沉淀为稳定能力。

替换 Jira 的项目，如果只完成“数据迁移 + 界面切换”，最终一定会回到老问题：流程各自为政、口径漂移、协作依旧靠人盯人。真正能把替换做成能力建设的，是你是否同步完成三件事（这也是最容易被忽略的“成功条件”）：

• 明确最小标准：统一核心对象与口径（需求、缺陷、版本、验收标准、关键状态）。
• 建立角色分工：流程 Owner（定义做法）、数据 Owner（定义口径）、平台 Owner（配置与集成）。
• 让机制驱动数据：例会、检查点、门禁与自动化，把更新状态变成流程的一部分，而不是额外负担。

我建议的迁移路线图通常是：小范围试点（跑通闭环）→ 样板复制（固化模板与口径）→ 数据度量（建立可信指标）→ 持续改进（用数据对话）。这样，你得到的不只是一个 Jira 替代软件，而是一套可复制的协作与治理能力。

结尾总结

选择 Jira 替代软件，本质上是在选择一种“组织协作操作系统”。轻量工具能快速降低沟通成本、提升推进效率，但上限取决于团队自律；工程型平台能建立更强的闭环与治理，但前提是组织愿意投入流程与口径建设。更稳妥的做法是：先用框架讲清楚目标能力，再用试点验证真实体验与迁移成本——把替换 Jira 从一次工具项目，升级为一次组织数字化能力建设。

DAS Agent是基于大模型技术，融合了阿里云10万+工单和专家经验的智能数据库运维大脑，专注于解决云数据库的日常运维及稳定性问题。

全新智能化运维体验，7*24小时扫描，助力万千企业迈入 AI-Native 运维时代，以深度诊断，运维提效，多引擎覆盖能力，实现企业运维能力平权，保障企业核心数据库业务持续在线。​

当前已支持主流的数据库：

• MySQL：RDS MySQL、PolarDB MySQL版、其他云厂商的MySQL、本地自建MySQL；
• PostgreSQL：RDS PostgreSQL、PolarDB PostgreSQL版、其他云厂商的PostgreSQL、本地自建PostgreSQL；
• Redis：云数据库Tair（兼容redis）、其他云厂商的Redis、本地自建Redis；
• MongoDB：云数据库MongoDB、其他云厂商的MongoDB、本地自建MongoDB；
• SQL Server：RDS SQL Server；
• 分布式数据库：PolarDB-X。

PC端：​​点此进入DAS Agent（屏幕右上角卡片）

移动端： 点此进入DAS Agent

功能说明

运维日报

每日自动分析 UID 下各 TP/NoSQL 实例健康度，统一输出高价值优化建议（如慢 SQL、存储、备份、安全、资源水位），DBA 无需逐个排查，变救火为预防；

SQL 优化

覆盖主流 TP 引擎，提供索引推荐、SQL 等价改写及上线前预检，效果明显优于传统代价计算/RDS Recommendation；

异常诊断

30+由资深DBA制作的运维skill，包含CPU、负载、I/O分析、死锁分析、Redis时延洞察等，快速定位根因并给出优化建议。

产品版本

DAS Agent 基础版

• 若当月超出10万字符，按0.01元/字符计费
• 最多支持1个Agent，可纳管10个实例

点此开通基础版：https://www.aliyun.com/product/hdm

DAS Agent企业版-SAAS

• 纳管实例数量分为20、40、60、80、100以及不限等多个档次
• 支持配置多个 Agent，同时无字符用量的限制

点此开通企业版：https://www.aliyun.com/product/hdm

参考资料

• 《DAS Agent 帮助文档》
• 《数据库智能运维产品 DAS Agent》
• 《DAS Agent、MCP Server 与 Dify 集成，实现跨账号数据库智能运维！》
• 《告别盲目排查，PolarDB+DAS Agent智能运维新突破》
• 《告别碎片化运维！阿里云 DAS Agent 助力10万+用户迈入多云数据库 AI-Native 运维时代》