b2894lxlx/tuanwei-java
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
49 Commits 1 Branch 0 Tags
8406c90cf33820302a9d66b5134c7485020e9c90
Commit Graph

49 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
weicw-dshsa 8406c90cf3 fix(ai): 文件上传按应用选择凭证；并入创意助手重试与失败日志（issue 11 / 14） 
同一文件内包含两块内容，无法拆分提交：

一、文件上传按应用选择凭证（issue 14，本次）
    Dify 的 /files/upload 是按应用鉴权的：实测同一张图、同一个 end user 下，chat Key
    上传得到的 file id 喂给创意助手工作流的 file-list 变量，0.2 秒即报
    Invalid upload file；用 creativeAssistant Key 上传的同一文件则 succeeded。
    而原实现只有两个分支（type 为空/0 用 chat，否则用 manuscript），从不使用创意助手
    的 Key，因此任何喂给创意助手的附件都必然失败 —— views/gxmu/creativeAssistant 表单页
    用的是同一个接口，它的附件功能同样是坏的（既有缺陷）。
    新增 app 参数按应用代号取凭证（复用 DifyProperties.AppKeys#byCode），不传时保持既有
    行为；未知代号回退旧逻辑并打 WARN。新增 resolveUploadToken。

二、创意助手出图失败的重试与可观测（issue 11，前次会话已完成验收、此前未提交）
    executeCreativeAssistantWithRetry / runCreativeAssistantOnce / CreativeRun /
    CreativeApiFailureException / creativeFailureReason / creativeFailureAnswer /
    isUpstreamCapacityFailure / isRetryableCreativeFailure / briefUpstreamError：
    上游 50500 算力不足时自动重跑一次，凭证失效、模型停用等不重试；每次失败按 ERROR
    打结构化日志（含失败节点名与上游原文截断）。
 2026-10-13 19:57:41 +08:00
weicw-dshsa f54e28cffc fix(ai): 失败态在返回体里带 status=failed，前端才能区分失败文案与正文（issue 10） 
上游工作流 failed 时，后端把 reply 置为失败文案（"生成失败，请稍后重试"）
并照常走成功路径返回（HTTP 200 / code=0），而返回体里**没有 status**：

    data = {"answer":"生成失败，请稍后重试", "conversationId":"…", "messageId":"…"}

两端前端的 isFailedPayload（读 payload.status / payload.data.status）因此
永远落空，只能把失败文案当正文渲染（实测三个 admin 页面都会这样）。
修 issue 09 时上游每次都 failed，这条是必现的。

改动：
- buildManuscriptResult 增加 failed 参数（保留三参重载，等价 failed=false，
  以免破坏 issue 08 既有测试的调用形态），失败时 put("status","failed")。
- 新增 buildActivityOutlineResult（同构），activityOutlineGen 收尾改用之。
- 两个方法都在外层作用域记录 workflowFailed：失败分支里有 continue，
  不能用分支内的局部布尔。

刻意不改的东西：
- 失败仍走 HTTP 200 / code=0。改成 code!=0 会与既有约定冲突、影响所有调用方
  的 catch 分支，本条只加一个字段即可让两端现有判定生效。
- answer 键在失败态下依然存在（issue 08 契约），只是现在有了 status 可区分。

测试：新增 AiWorkflowFailureHttpStatusTest 8/8，含反向用例——
成功态**不得**带 status（否则 isFailedPayload 会误伤正常结果），
以及「成功态正文恰好是失败文案」时唯一判据是 status。
全量 210 跑 0 失败（2 个 ServerContainer not available 为预存问题）。

验证：用桩上游（probe/stub-dify-failure.py，回 workflow_finished{status:failed}）
起第二个后端实例，实测两条链路的返回体都带 status='failed' 且
answer 仍为可读文案，前端 isFailedPayload 判定为 true —— 全链路闭合。
 2026-10-13 02:12:46 +08:00
weicw-dshsa fbc9774e19 fix(ai): 大纲链路补齐上游必填变量，资金归一化为数值（issue 09） 
活动策划大纲当时必然失败，界面只显示「生成失败，请稍后重试」。
两条根因（单变量对照实测确证）：

1. Dify 开始节点 event_funding 是 number，而实体与两端前端都是字符串，
   小程序问答助手页默认值还是中文「待定」→ must be a valid number，0.2s 即 failed。
2. event_member / tel_people 是上游必填变量，实体里根本没有字段，从不发送
   → event_member is required in input form。

实施中发现的关键事实，推翻了 issue 初稿的一条建议：
「is required in input form」检查的是键是否存在，不是值是否非空 ——

  缺 event_member 键 / null  → failed: is required in input form
  "event_member": ""        → succeeded（4752 条 message）
  "event_funding": ""       → succeeded（7268 条 message）
  "event_funding": "待定"    → failed: must be a valid number

所以「干脆不发该字段」行不通（不发 = 报 required），正确做法是键始终下发、
值空串兜底。

改动：
- ActivityOutlineInputs 补 eventMember / peopleManage / telPeople 三字段
  （snake + 驼峰别名）；eventFunding 保持 String 承载用户原文。
- buildActivityOutlineInputs：6 个上游必填变量无条件占位（空值走空白转空串，
  不能给 null —— null 会被上游当缺失）；event_type / event_location /
  people_manage / event_meme 实测非必填，保持「为空不发」。
- 新增 normalizeEventFunding：抽出首个金额并归一化为 BigDecimal。
  两个必须先处理的坑，否则静默发出错误金额（比留空更糟）：
    · 日期：'2026年4月办活动，预算5000元' 的 2026 会被当金额 → 先剔除日期
    · 单位前空格：'预算 1 万元' 只认紧邻的「万」会抽成 1 元 → \s* 容忍
  另支持 万/亿/千/百 倍率与 '3万5千' 连续降序单位相加；抽不出即降级空串。
- 前置校验抽成 validateActivityOutline，只校验主题/受众/时间三项。
  刻意不校验另外三个上游必填项 —— 上游必填不等于用户必填，加校验会把两端
  默认入参挡在门外（改前端默认值为空串后，旧校验会直接返回
  'event_funding不能为空'，比原缺陷更糟）。
- buildLoadingText 加 120 字上限：agent_thought 的思维链实测可达数 KB，
  整段塞进 loading 气泡等于把思维链推给端上。
- 去掉 isDisplayableText 之后的恒假条件（空串已被排除），并注释说明
  reply.indexOf("") 恒为 0 会误判已存在，故两道判断都不能少。

配套前端：
- uniapp 问答助手页资金默认值 '待定' → ''（未提及 != 待定）
- admin 入参类型补注释与 3 个可选键

测试：新增 AiActivityOutlineContractTest 23/23，含「凡校验放行的入参必带上游
全部必填键」的不变量用例；AiManuscriptUuidLeakTest 增至 21 条，补 loading
长度上限与真实 message_end 形状。全量 202 跑 0 失败
（2 个 ServerContainer not available 为预存问题）。

验收：probe/outline-e2e.py 走真实后端，用两端前端默认入参与 issue 原文要求的
'待定' 一档，复刻 apiRequest 回落 + formatOutlineResult + parseAssistantContent
判定，29/29 PASS。
 2026-10-13 00:37:15 +08:00
weicw-dshsa a8c8dd8643 feat(dify): 全部迁移到内网实例，统一为单份配置 
VPN 打通后开发机可直连内网，原先「默认公网 + prod 覆盖内网」的双份配置
已无必要，且两套 Key/知识库 ID 完全不通用（实测互打一律 401），
留着只会造成误用。公网那套整体移除，回退到 git 历史取。

- application.yml：base-url 与 8 个应用 Key、全部知识库密钥/ID 改指内网；
  原默认值来自公网，其注释同步改写
- application-dev.yml / application-prod.yml：删除 dify 覆盖段。
  YAML map 是按键合并而非整体替换，保留一份与默认值相同的覆盖
  只会在将来漏改时混出「一半内网一半公网」的状态
- DifyProperties：默认 baseUrl 改内网，类注释同步

修复一个上线起就坏的接口：

- admin 端「竞赛历史」文档列表按 challenge-cup 取库，而该 ID
  b342f096-… 在**公网实例上也返回 404**（公网真实的挑战杯库是
  7c812029-…，从未登记），故该接口一直不可用。改指内网「竞赛案例」
  库（181d58e3-…，145 篇），实测已能列出文档。对外路径保持
  /challenge-cup/documents 不变，以免影响 admin 端调用

清理失效的工作流变量（内网实测已从开始节点移除）：

- document-process 的 query / pdf_url，declaration 的 parse_value。
  三者配置为空串以显式丢弃 —— 直接删行会退回「按原名透传」，
  反而把 pdfUrl / parseValue 这类驼峰名发给 Dify。实体字段保留，
  不破坏 /documentProcess/upload 的入参契约（pdfUrl 仍参与
  「必须提供文件或 pdfUrl」的校验，只是不再转发）
- 注：Dify 对多传变量静默忽略，故此前不报错、功能未受影响，
  属「看着对其实无效」的配置

测试：改断言为内网值，并新增「不残留任何公网配置」「失效变量必须
配成空串」等防回归用例；变异验证（base-url 改回公网 / 空串改回生效名）
确认用例有真实判别力。Dify 相关 44 例全绿。

Refs: .scratch/dify-probe/README.md, .scratch/ai-assistant/map.md
 2026-10-12 12:37:33 +08:00
weicw-dshsa a2a83f7d9e fix(ai): 稿件/大纲链路失败态不再把标识符当正文推给端上 
这三条路径在 workflow_finished 事件只 extractAnswer、从不读 status：
工作流失败时 outputs 为空、answer 可能被填成 workflow_run_id(UUID)，
原样下发等于把内部标识符当正文推给端上（issue 03）。

- activityOutlineGen：失败先判定，推「生成失败，请稍后重试」(reset=true)
  再正常收尾
- executeWorkflowForResult：同上；最终结果失败时只回 status + 可读文案，
  不带 outputs / raw
- manuscriptGen：自查发现该方法不走通用执行、自带一份缺口，一并补齐
- socket 发送器增加 reset 字段：端上收到后丢弃失败前已累积的半截内容
- 新增 AiWorkflowFailureStatusTest 10 例：锁定「失败判定先于取 answer」
  的顺序契约与顶层/嵌套 status、大小写空白、成功不误判等边界

Refs: .scratch/ai-assistant/issues/03-other-links-raw-payload-fallback.md
 2026-09-24 04:22:29 +08:00
weicw-dshsa c598d88506 test(ai): 补端到端形状契约用例 
把 buildCreativeAssistantResult 在失败态下的**真实产出**打成一行 JSON，
供 .scratch/ai-assistant/verify-frontend-e2e.js 当输入喂给前端真实渲染函数，
验证的是「后端真实产出 → 前端真实渲染」整条链路，而非两侧各自自测。

实测产出为 {"status":"failed","answer":"生成失败，请稍后重试"}，
不含 raw / workflow_id / req_id / 上游错误栈。

Refs: .scratch/ai-assistant/issues/01-creative-assistant-raw-json-bubble.md
 2026-09-24 03:51:49 +08:00
weicw-dshsa 23a7f001cc fix(ai): 创意生成工作流失败时不再把原始报文吐给用户 
Dify 以 workflow_finished + data.status=failed + outputs={} 收场时，后端只搬运
字段、从不读 status，把一个失败结果包成 success 下发，且把整包报文塞进 raw；
前端 formatCreativeResult 取不到业务字段就落到 text || stringifyUnknown(payload)，
整段原始 JSON（含 workflow_id / task_id / req_id 与上游错误栈）进了聊天气泡。

- 新增 workflowStatus / isWorkflowFailed：失败时只回 status + 可读 answer，
  不下发 outputs / raw，不携带上游错误文本
- executeCreativeAssistant 的 workflow_finished 分支先判失败，命中则直接返回，
  不再用流式片段或 taskId 覆盖失败文案
- 失败报文顶层 answer 是 workflow_run_id(UUID)，故失败文案用固定字符串，
  不取自 answer
- 新增 AiCreativeFailureResultTest：13 个用例，样本为 issue 原文的真实失败报文

Refs: .scratch/ai-assistant/issues/01-creative-assistant-raw-json-bubble.md
 2026-09-24 03:44:08 +08:00
weicw-dshsa cbbe3b87b4 修改端口号 2026-09-22 20:35:21 +08:00
weicw-dshsa 7a90d79352 修复统一身份认证登录：补回从未提交的 gxmu.auth 配置 
线上 /api/sso/login 报「学校统一身份认证未配置，请联系管理员」，
/api/sso/available 返回 false。根因不是代码，是配置：gxmu.auth 段
只存在于本地工作区，从未进入任何一次提交。

证据：git log -S GXMU_AUTH_APPID 只命中两处，都不是 application.yml ——
LyuapAuthClientIT 里硬编码的兜底值，以及 .scratch/student-sso/README.md
第 5.1 节那句「已写进 application.yml」。而 6f04a64（新增统一身份认证登录）
的 13 个文件全在 src/main/java 与 src/test，根本没碰 resources。

后果：GxmuAuthProperties.appId 默认为 null → available() 为 false →
login() 在凭据校验处直接抛异常，请求根本到不了认证平台。

之所以单测全绿而功能全废：SsoLoginServiceImplTest 把 GxmuAuthProperties
整个 mock 掉了（getAppId 固定返回 "gxmu-app"），这类测试永远发现不了
「yml 里没这一段」。Dify 那批配置当初踩的也是同一类坑。

- application.yml 补回 gxmu.auth 段：enabled/base-url/app-id/app-secret/
  timeout-ms/allow-unknown-user，与 openplat 凭证同样处理，默认值写入
  并保留 GXMU_AUTH_APPID / GXMU_AUTH_APPSECRET 环境变量覆盖
- 新增 GxmuAuthPropertiesBindingTest：照 DifyProdProfileBindingTest 的做法
  直接绑定 yml 断言，不启动容器、不依赖数据库与 Redis。四条用例先红后绿，
  最后一条是端到端语义 —— 配置齐备时 available() 必须为 true，而不只是
  「配置字段非空」

已联网验证（真实打到 cas.gxmu.edu.cn）：available 由 false 变 true；
不存在的学号返回平台业务码「学号不存在，请确认后重试」，证明 appid 与
secret 已被平台认下。

注：TestMain / WebSoftApplicationTests 两项失败为预先存在，
已用 git stash 在改动前复现同一错误（serverEndpointExporter 的
ServerContainer not available），与本次改动无关。
 2026-09-21 19:58:48 +08:00
weicw-dshsa 8c994d9ed2 Dify 配置外置并切至内网实例 
接口地址与各应用 API Key 原先硬编码在 AiController 与
KnowledgeBaseController 中，换环境要改代码、密钥还会散落在多处。
新增 DifyProperties 统一收敛到 dify 配置节点，并补上文档中缺失的
两个应用与知识库管理接口。

- 新增 DifyProperties，外置 base-url / 8 个应用 Key / 知识库密钥，
  默认值保持公网实例，本地开发不受影响
- 生产 profile 覆盖为内网 10.100.158.15，含全部 8 个应用 Key 与
  两个知识库的独立密钥
- 新增申报书生成、智能文档处理两个工作流接口（含文件上传版本），
  接入既有的 WebSocket 流式推送与停止机制
- KnowledgeBaseController 补齐知识库增删改查、文档管理与索引进度，
  并对文档状态动作加白名单，避免路径参数被任意拼接
- 修正 AI 内容创作的 number 变量名：Dify 侧为 Number，
  变量名大小写敏感，此前一直发送小写导致该功能缺参
- 生产下显式覆盖公网知识库 ID 的密钥：YAML 的 map 按键合并而非整体
  替换，不覆盖会残留指向公网实例的死密钥

工作流变量名取自内网实例实测（probe-dify.sh），其中申报书生成与
文档处理两组变量与公网命名习惯不一致，故以配置映射承载，改名只需
改 yml 而非改代码。

新增 18 项测试，覆盖配置绑定、profile 覆盖完整性（逐项断言 8 个
Key 均已覆盖且不残留公网 Key）与入参到 Dify inputs 的映射。
 2026-09-21 19:46:49 +08:00
weicw-dshsa 3e2d7b65a6 教师同步派生登录账号 
同步教师名册时，若存在手机号则建号：手机号即 username/phone，
后六位即密码，user_code 存教工号（这是与名册之间唯一稳定的反查键，
后台用户管理页改不了——手机号可改，用它反查会在改号后断链）。

推翻 ADR-0001 中「教师不建账号」的结论，见新增的 ADR-0008。
学生仍走认领，不受影响。

只建账号、不建角色：teacher 角色由运维在后台创建，代码查不到时
静默跳过。授角色逻辑同时挂在「新建」与「账号已存在」两个分支上，
因此运维建完角色后重跑一次同步即可给全部已有账号补齐。

停用冻结带 20% 比例护栏：全量同步若因平台异常拉回部分数据，
差集会把大批在职教师误判为消失。误停用名册是数据不准（可重跑），
误冻解是安全问题（离职教师仍能登录），两侧取舍不对称，宁可漏冻结。

开关 gxmu.openplat-sync.teacher-account.enabled 默认关闭。
 2026-09-19 20:39:13 +08:00
weicw-dshsa b6c392141e 学生认领新增按学号认领（不校验姓名） 
学号已在认证平台持密码验过，属可信来源，不必再用姓名二次校验
（名册姓名与平台姓名格式不一致时会误伤）。名册无此学号、已被他人
认领仍返回 false。
 2026-09-18 23:31:01 +08:00
weicw-dshsa 6f04a64084 新增学校统一身份认证登录 
- GxmuAuthProperties 承载接入配置，认证客户端按微服务认证平台 API v2.3 调 cas.gxmu.edu.cn
- /api/sso/login 与 /api/sso/available 免鉴权放行
- 校验通过后按学号认领学生，名册外的账号默认拒绝登录
 2026-09-18 23:31:00 +08:00
weicw-dshsa 45b7a42331 移除基础配置里冗余的 redis 连接项 
这些值与 Spring Boot 的默认值一致（127.0.0.1:6379 / db 0 / 空密码），
生产环境由 application-prod.yml 覆盖，删掉不改变行为。
 2026-09-15 17:21:35 +08:00
weicw-dshsa 853f3c3f5b 新增教师名册只读接口 
教师名册来自开放平台全量同步，只用于检索与选人（教师不建登录账号，ADR-0001），
因此不提供认领类接口，也没有可写字段。

- GET /api/gxmu/teacher/page：学院/教工号/姓名/状态筛选，默认只返回启用
- POST /api/gxmu/teacher/export：导出用列表，带操作日志
- 权限拆成 gxmu:teacher:list 与 gxmu:teacher:export
- 手机号按 spec §5.2 落盘但不进任何列表接口，返回前一律清空（hideSensitive）
- 菜单与按钮权限见 sql/20260915_add_teacher_roster_menu.sql，可重复执行
 2026-09-15 17:21:32 +08:00
weicw-dshsa 582d7dfbcb 学生同步稳态只写变更行 
实测写入才是大头，不是平台拉取：9.8 万行的表上 800 行/批 upsert 要 716ms，
123 批共 88 秒；而窄读全部 (xh, row_hash) 只要 2.1 秒。

做法：
- gxmu_student 增列 row_hash，存放「平台权威字段」的 MD5 指纹
  （迁移 sql/20260915_add_student_row_hash.sql，可重复执行）
- 同步时先窄读现有指纹，只 upsert 指纹变化的行
- 窄读同时服务于停用差集，省掉原先单独的一次 selectAllXh
- deactivateByXh 顺带把 row_hash 置空，保证停用行以后重新出现时一定被重新写入

指纹规则单独成类 StudentFingerprint：它必须与 mapper 的
ON DUPLICATE KEY UPDATE 子句严格对应——往 UPDATE 里加字段却忘了加进指纹，
那一列就会静默地不再更新，这类 bug 不报错、只产生过期数据。
因此附有逐字段的测试，并由 MapperFieldWhitelistTest 守住 UPDATE 子句本身。

附带收益：未变更的行不再刷新 update_time，该字段恢复「最后变更时间」的含义；
码表修正后 nation/politics 变化会触发自动重算，正是 ADR-0006 承诺的行为。

预期学生同步 170 秒 -> 约 85 秒，其中写库 88 秒 -> 约 2 秒。
现有 98187 行 row_hash 为空，部署后第一次仍会全量写一次。
离线单测 50 个。
 2026-09-15 16:14:05 +08:00
weicw-dshsa cd54039f28 接入医科大开放平台数据同步 
新增 com.gxwebsoft.gxmu.openplat：开放平台客户端（oauth 鉴权、token 缓存与失效
重取、分页拉取）、部门/教师/班级/学生四段同步、异步编排与手动同步接口、学生认领、
学生名册查询与导出、每天 03:30 的定时任务、同步记录。

关键设计：
- 名册与登录账号分离，学生通过「认领」（手机号自动 / 学号姓名自助）关联 sys_user
- 组织数据以 sys_organization 为唯一载体，gxmu_college 废弃
- 平台无可用增量字段，只做全量拉取 + 幂等 upsert
- 上游消失只停用不删除，且只作用于同步来源的记录（避免误停用人工维护的研究生班）
- 平台权威字段按白名单覆盖，人工字段不触碰
- 码表可配置并保留原始码，码值实测存在两套编码混用，不做硬编码
- 手动同步为异步：提交返回批次号，前端轮询 /status 看分段进度

性能：
- 班级/部门由逐条 update 改为多行 upsert，班级 1584 条 41s -> 0.19s
- 码表解析加进程内缓存，学生同步由 >17 分钟不完成 -> 170 秒完成 98187 行

迁移脚本需手动执行（可重复执行）：
  sql/20260912_create_openplat_sync_tables.sql
  sql/20260912_add_openplat_menu.sql

离线单测 43 个；另有联网集成测试 OpenPlatformClientIT（需 -Dopenplat.it=true）。
 2026-09-15 15:54:49 +08:00
b2894lxlx f379291e4f 260720 2026-07-20 11:48:06 +08:00
b2894lxlx 7119dc76a9 250826 2025-08-26 21:29:55 +08:00
b2894lxlx 1a35b30c7e 250522 2025-05-22 10:28:37 +08:00
b2894lxlx bfbde8a0f5 250522 2025-05-22 10:27:57 +08:00
b2894lxlx 9139457203 240401 2024-04-01 22:11:01 +08:00
gxwebsoft 1a47ed7630 新增配件管理模块 2024-02-27 20:45:12 +08:00
gxwebsoft 349ef16c20 新增配件管理模块 2024-02-27 20:29:16 +08:00
gxwebsoft 89bcd98570 完成保养记录和厂内维修模块 2024-02-25 19:33:40 +08:00
gxwebsoft 3c22a60a1c 完成安全维保管理模块 2024-02-25 15:23:54 +08:00
gxwebsoft d72849ad50 新增采购入库功能 2024-02-05 21:48:07 +08:00
gxwebsoft 20f190410c 新增标准节、优化设备统计 2024-02-05 15:54:54 +08:00
gxwebsoft 426d0a685a 合并代码 2024-02-03 16:42:16 +08:00
b2894lxlx bfefa9a787 调整 2024-01-31 14:55:59 +08:00
b2894lxlx 2fd8b3d341 调整 2024-01-31 14:54:49 +08:00
b2894lxlx 71e28fd448 新增收款; 
新增项目结算书
 2023-06-18 11:02:37 +08:00
b2894lxlx d61e7b163d 新增转租管理; 
结构调整
 2023-06-17 12:39:19 +08:00
b2894lxlx ff87369bab 新增历史结算; 
新增租单管理
 2023-06-13 01:44:45 +08:00
b2894lxlx 65f21b7d0a 新增历史结算; 
新增租单管理
 2023-06-13 01:44:40 +08:00
b2894lxlx 8307a16689 完善合同管理; 
新增结算管理
 2023-06-12 01:32:34 +08:00
b2894lxlx 385bfb96b8 新增客户管理; 
新增合同管理
 2023-06-10 01:29:06 +08:00
gxwebsoft 484999cd07 合并代码 2023-06-09 12:30:28 +08:00
gxwebsoft 61db0f4b5a Merge remote-tracking branch 'origin/master' 2023-06-08 19:30:30 +08:00
gxwebsoft 6e3bd8f55f 新增项目管理 2023-06-08 19:30:24 +08:00
weicw 83d918a467 删除无用字段 2023-06-08 12:38:25 +08:00
weicw 6b9d4c4ef8 关键字模糊搜索 2023-06-06 12:45:36 +08:00
weicw f1b1ab0642 产权公司 2023-06-06 10:26:38 +08:00
weicw a53406898f 防坠器 2023-06-05 22:57:09 +08:00
gxwebsoft 47e758e22f 修复设备分类和设备型号问题 2023-06-05 17:06:07 +08:00
gxwebsoft d2a82a97e6 初始化 2023-06-04 11:18:05 +08:00
gxwebsoft 536f8079b0 初始化 2023-06-04 00:35:22 +08:00
gxwebsoft 428e4996f9 初始化 2023-06-04 00:28:12 +08:00
南宁网宿科技 912944faea Initial commit 2023-06-03 23:56:49 +08:00