鸿蒙原生应用 ArkTS 严格模式实战：虚线上传卡与类型胶囊 —— 科研文件管理页设计

App 24「科研项目管理」文件 Tab（Func2Tab），是科研文件管理页——4 模块布局：Header + 5 分类 Chip（全部/论文/数据集/报告/代码）+ 虚线边框上传卡 + 6 文件列表（emoji + 名称 + 大小/日期 + 类型胶囊）。本篇基于 24-research-mgmt/entry/src/main/ets/pages/Func2Tab.ets（约 118 行）逐段拆解，附 4 张实机截图。

一、整体结构：Header + Chip + 上传卡 + 文件列表

Func2Tab 是"文件管理"的 4 模块布局——4 模块覆盖"分类+上传+列表"完整文件管理：

build() {
  Column() {
    this.Header()
    Scroll() {
      Column({ space: 14 }) {
        this.ChipRow()
        this.UploadCard()
        this.SectionTitle('项目文件')
        this.FileList()
      }
      .width('100%')
      .padding({ left: D.pad, right: D.pad, top: 14, bottom: D.pad + this.safeBottom + 20 })
    }
    .layoutWeight(1).scrollBar(BarState.Off).align(Alignment.Top)
  }
  .width('100%').height('100%').backgroundColor(C.bg)
}

4 块结构：

  1. Header — "文件管理"标题
  2. ChipRow — 5 分类胶囊（全部/论文/数据集/报告/代码）
  3. UploadCard — 虚线边框上传卡
  4. SectionTitle('项目文件') + FileList — 6 文件列表

"文件管理"的标准 4 模块——"分类 → 上传 → 列表"——用户操作流程清晰。

项目源码开源：https://gitee.com/codenestFlow/HarmonyOSHub

二、Header

Header 是"文件管理"单行（与系列同款 height(safeTop + 56) + 靠底对齐）：

@Builder Header() {
  Row() {
    Text('文件管理')
      .fontSize(20).fontWeight(FontWeight.Bold).fontColor(C.text)
  }
  .width('100%').height(this.safeTop + 56)
  .padding({ top: this.safeTop, left: D.pad, right: D.pad })
  .backgroundColor(C.card)
  .alignItems(VerticalAlign.Bottom)
}

"文件管理"是功能名（不是"项目"）——"Tab 内页面"的功能名——"Header 标题 = 用户当前所在的功能"。

科研管理文件页首屏 · 文件管理Header+5分类Chip(全部/论文/数据集/报告/代码)+虚线边框上传卡+论文初稿v3+实验数据集v2

三、ChipRow：5 分类胶囊

ChipRow 是 5 分类的横滑胶囊（与系列其他 Chip 同款）：

@Builder ChipRow() {
  Scroll() {
    Row({ space: 10 }) {
      ForEach(this.cats, (cat: string, idx: number) => {
        Text(cat)
          .fontSize(13)
          .fontColor(this.activeCat === idx ? '#FFFFFF' : C.textSub)
          .padding({ left: 14, right: 14, top: 7, bottom: 7 })
          .backgroundColor(this.activeCat === idx ? C.primary : C.card)
          .borderRadius(16)
          .onClick(() => { this.activeCat = idx; })
      }, (cat: string) => cat)
    }
  }
  .scrollable(ScrollDirection.Horizontal).scrollBar(BarState.Off).width('100%')
}

5 分类：['全部', '论文', '数据集', '报告', '代码']——科研项目的 4 类文件 + 全部——"全部 + 4 业务分类"是 5 个分类的标准设计。

@State activeCat: number = 0 默认选中"全部"——onClick 切选中态——"假筛选"（demo 未联动过滤）。

4 个业务分类的"科研文件分类"标准：

  • 论文（.docx/.pdf）——研究成果
  • 数据集（.csv/.xlsx）——研究素材
  • 报告（.pdf）——阶段性产出
  • 代码（.zip/.py）——实验工具

"文件分类 = 科研流程产物"——真实项目的"4 大文件类型"映射"4 大研究阶段"。

四、UploadCard：虚线边框上传卡

UploadCard 是**"上传文件"引导卡**——用虚线边框+主色强调（上传功能的标准视觉）：

@Builder UploadCard() {
  Row({ space: 10 }) {
    Text('📤').fontSize(24)
    Text('上传文件').fontSize(14).fontColor(C.text).layoutWeight(1)
    Text('论文/数据/报告/代码').fontSize(11).fontColor(C.textDim)
  }
  .width('100%').padding(14)
  .backgroundColor(C.card).borderRadius(D.rMd)
  .border({ width: 1, color: C.primary, style: BorderStyle.Dashed })
  .onClick(() => { promptAction.showToast({ message: '上传文件' }); })
}

3 元素：

  1. 📤 上传 emoji（24sp）
  2. "上传文件"（14sp）—— layoutWeight(1) 占主要空间
  3. 支持的文件类型（11sp 灰）—— "论文/数据/报告/代码" ——"提示用户能上传什么"

border({ width: 1, color: C.primary, style: BorderStyle.Dashed }) —— "1vp 虚线 + 靛蓝边框" ——虚线边框是"上传占位符"的视觉约定（任何上传卡都用虚线）——"虚线 = 待填充"。

真实项目的"上传卡"进阶：

  • 拖拽上传：把文件拖到卡上 → 自动上传
  • 点击上传：点击卡 → 弹文件选择器
  • 粘贴上传：Cmd+V 粘贴文件 → 自动上传
  • 多文件上传：选择多个文件 → 批量上传

App 24 的"点击弹 Toast"是占位实现——真实项目应集成 @ohos.file.picker 文件选择器。

五、SectionTitle + FileList：6 文件列表（本页核心）

SectionTitle 是"项目文件"标题（无右侧"新建"——上传入口已经在 UploadCard 单独提供）。FileList 是 6 文件列表：

@Builder FileList() {
  Column({ space: 10 }) {
    ForEach(this.files, (f: FileItem) => {
      Row({ space: 12 }) {
        Text(f.emoji).fontSize(24)
        Column({ space: 3 }) {
          Text(f.name).fontSize(14).fontColor(C.text).maxLines(1)
            .textOverflow({ overflow: TextOverflow.Ellipsis })
          Text(f.size + ' · ' + f.date).fontSize(11).fontColor(C.textDim)
        }.alignItems(HorizontalAlign.Start).layoutWeight(1)
        Text(f.type).fontSize(11).fontColor(C.primary)
          .padding({ left: 6, right: 6, top: 2, bottom: 2 })
          .backgroundColor(C.primarySoft).borderRadius(4)
      }
      .width('100%').padding(12).backgroundColor(C.card).borderRadius(D.rMd).border({ width: 1, color: C.stroke })
      .onClick(() => { promptAction.showToast({ message: f.name }); })
    }, (f: FileItem) => f.id.toString())
  }.width('100%')
}

5.1 6 个文件的数据

private files: FileItem[] = [
  { id: 1, emoji: '📄', name: '论文初稿_v3.docx', type: '论文', size: '2.4MB', date: '今天' },
  { id: 2, emoji: '📊', name: '实验数据集_v2.csv', type: '数据集', size: '15.6MB', date: '昨天' },
  { id: 3, emoji: '📝', name: '实验报告_阶段2.pdf', type: '报告', size: '3.1MB', date: '8月10日' },
  { id: 4, emoji: '💻', name: '模型训练代码.zip', type: '代码', size: '8.2MB', date: '8月8日' },
  { id: 5, emoji: '📄', name: '参考文献.pdf', type: '论文', size: '1.8MB', date: '8月5日' },
  { id: 6, emoji: '📊', name: '评估结果.xlsx', type: '数据集', size: '420KB', date: '8月3日' }
];

6 文件覆盖 4 类型：

文件类型大小日期
📄 论文初稿_v3.docx论文2.4MB今天
📊 实验数据集_v2.csv数据集15.6MB（最大）昨天
📝 实验报告_阶段2.pdf报告3.1MB8月10日
💻 模型训练代码.zip代码8.2MB8月8日
📄 参考文献.pdf论文1.8MB8月5日
📊 评估结果.xlsx数据集420KB（最小）8月3日

4 文件类型分布：论文 2 个 / 数据集 2 个 / 报告 1 个 / 代码 1 个——"论文+数据集"是科研项目最常见的 2 类文件。

文件命名规范："论文初稿_v3.docx"（含版本号 _v3）/ "实验数据集_v2.csv"（含版本号 _v2）——"版本号 _v1/_v2/_v3"是科研文件的标准命名（Office 365/Google Docs 也用版本管理）——"版本管理"是科研文件的标配。

"阶段2"是报告命名规范——"阶段1/2/3 报告"是项目阶段的里程碑——"阶段化产出"是科研项目的流程。

6 文件按日期倒序：今天 → 昨天 → 8月10日 → 8月8日 → 8月5日 → 8月3日——"最新文件在最上"是文件列表的标准（对比 App 22 记录按状态分组、App 23 文件按状态分组——App 24 按时间倒序）。

5.2 文件卡 4 元素

每行 4 信息：

  1. emoji 类型图标（24sp）——📄/📊/📝/💻（按文件扩展名分类）
  2. 文件名（14sp 深色，maxLines(1) 截断）
  3. 大小 + 日期（11sp 灰）——"2.4MB · 今天"
  4. 类型标签（11sp 靛蓝 + 浅靛底）

"emoji 按文件类型"——.docx → 📄 / .csv → 📊 / .pdf → 📝 / .zip → 💻——"emoji 替代文件扩展名图标"——demo 简化（真实项目应用文件类型图标）——**"emoji 识别度足够"**对一般用户友好。

"大小 + 日期"用 · 分隔——"两个次要信息"紧凑展示（一行 2 信息）。

类型标签（靛蓝字 + 浅靛底 + 4vp 圆角）——"文件类型"是科研文件的核心元数据——"4 种类型 = 4 种业务"（论文/数据集/报告/代码）。

六、@State 与"文件管理"数据

Func2Tab 有 1 个 @State：activeCat（分类 0-4）——"1 个 @State 驱动 Chip 视觉"（同系列其他 Chip）。files: FileItem[] 是 private 普通数组（不上 @State）。

"假筛选"——点击 Chip 只切 activeCat，不联动过滤——demo 简化（真实项目应加 filteredFiles() 按 type === cats[activeCat] 过滤）。

真实项目的"文件上传后自动刷新"：

@State files: FileItem[] = [...];
async uploadFile(file: FileItem) {
  // 上传到服务器
  await uploadAPI(file);
  // 整体替换触发渲染
  this.files = [file, ...this.files];
}

"上传后整体替换数组"——@State 数组 + 整体替换 = ArkUI 响应式数组的标准写法。

七、"虚线边框上传卡" vs "实线 + 按钮上传"

App 24 的 UploadCard 是**"虚线边框 + 整卡可点击"**——对比其他上传设计：

设计适用场景优势
虚线边框整卡（App 24）工具型 App 轻量上传视觉突出、整卡可点
实线 + 上传按钮复杂上传（多文件/进度）功能明确、按钮集中
拖拽上传桌面端高效
+ 浮动 + 按钮移动端高频随时上传

"虚线边框整卡" 是"工具型 App"的最佳轻量上传设计——"虚线 = 待填充" + 整卡可点 = 简化且功能完整。

真实科研文件管理的"4 类上传场景"：

  • 论文初稿（.docx）
  • 实验数据（.csv/.xlsx）
  • 报告（.pdf）
  • 代码（.zip/.py/.ipynb）

"上传时按类型自动分类"是进阶功能——上传 .docx 自动归"论文"、上传 .csv 自动归"数据集"——"类型识别"减少用户操作。

八、文件大小与日期的"科研文件特征"

App 24 的 6 文件大小（420KB ~ 15.6MB）——"科研文件大小范围"：

类型典型大小原因
论文 (.docx/.pdf)1-5MB纯文字+少量图
报告 (.pdf)2-10MB文字+图表
代码 (.zip)1-50MB大量文件压缩
数据集 (.csv/.xlsx)100KB-100MB+行数决定

"评估结果.xlsx 420KB"——比数据集小很多（评估结果是聚合后的摘要数据）——"数据集 15.6MB"是原始数据——"大小反映数据规模"。

"日期命名 + 版本号"是科研文件的核心元数据——"v1/v2/v3"显示迭代历史、"8月10日"显示时间线——真实项目的"文件版本管理"应支持"查看历史版本/回滚"。

科研管理文件页下部 · 6文件完整列表(论文/数据集/报告/代码4类型胶囊)+类型标签

九、文件管理与项目管理的"数据流"

**项目（首页）→ 任务（项目详情）→ 文件（文件管理）**是科研管理的 3 大模块：

模块包含关系
项目4 个项目卡片顶层组织
任务5 任务（每个项目 5 任务左右）项目的执行项
文件32 个文件（按项目分）任务/项目的产物

"项目 → 任务 → 文件"的层级：

项目（首页）
  ├─ 任务（项目详情）
  └─ 文件（文件管理）

真实项目应"文件按项目分组"——App 24 当前 6 文件硬编码（不与 4 项目关联）——真实项目文件列表应按"项目"过滤（"项目 A 的 6 个文件"）——"文件归属于项目"是真实的数据关系。

科研管理文件页中段 · 4分类Chip+虚线上传卡+6文件列表(论文初稿v3/实验数据集v2/实验报告/模型训练代码/参考文献/评估结果)

十、文件管理的"科研 4 类型" vs "办公 5 类型"

App 24 的文件分类（论文/数据集/报告/代码）是"科研项目"的 4 类——对比"办公文档"的 5 类：

科研 4 类（App 24）办公 5 类
论文（.docx/.pdf）文档（.docx）
数据集（.csv/.xlsx）表格（.xlsx）
报告（.pdf）演示（.pptx）
代码（.zip/.py）图片（.png/.jpg）
PDF（.pdf）

"科研文件分类"和"办公文件分类"的差异：

  • 办公：按文件格式分（docx/xlsx/pptx/png/pdf）
  • 科研：按文件用途分（论文/数据集/报告/代码）

"用途 vs 格式"是分类哲学的差异——科研关心"这文件是做什么的"（论文/数据集）、办公关心"这文件是什么格式"（Word/Excel）——"业务导向 vs 工具导向"。

真实项目应"按业务分类为主、格式分类为辅"——"用途分类 = 用户视角"（用户知道这是什么类型的文件）、"格式分类 = 系统视角"（系统按 MIME 类型分）——App 24 的"用途分类"是用户友好设计。

科研管理文件页底部 · 6文件完整+安全区留白+底部Tab栏

十一、"版本管理"与 Git LFS

App 24 的文件名带版本号（_v3 / _v2）——真实项目应支持"版本管理"系统：

"文件版本管理"的 3 个阶段：

  1. 本地版本（App 24 当前）——文件名加 _v1/_v2/_v3 后缀
  2. 工具版本（Git）——commit hash 标识每个版本（git v3.2.1）
  3. 平台版本（Git LFS）——大文件版本管理（专门处理 100MB+ 文件）

科研文件的"大文件"挑战：

  • 数据集常常 100MB+（不能直接用 Git）
  • 代码常常多文件（.zip 压缩）
  • 论文版本多（v1-v10 不断迭代）

"Git LFS"（Git Large File Storage） 是科研/媒体项目的标准——大型文件不进 Git 主仓库、进 LFS 单独存储。

App 24 简化为"文件名 _v3" ——真实项目应集成"版本历史/回滚"——"文件版本管理"是科研项目的刚需。

十二、虚线边框上传 vs 拖拽上传

App 24 的"虚线边框整卡可点"是最简上传——对比其他上传设计：

设计适用优势
虚线边框整卡（App 24）工具型轻量视觉突出
拖拽上传桌面端高效
浮动 + 按钮移动端高频随时上传
+ 模态弹出大文件集中操作

"虚线整卡"是移动端的轻量方案——移动端屏幕小、拖拽不便，"点击卡 = 选文件"是最自然交互。

真实科研项目应支持 3 种上传方式：

  1. 本地文件：点击 → @ohos.file.picker 选择
  2. 拍照上传：📷 按钮 → 相机 API（实验记录场景）
  3. 云盘同步：☁️ 按钮 → OneDrive/Google Drive（协作场景）

"3 种上传 = 3 种使用场景"——App 24 只支持 1 种"是 demo 简化"——真实项目应按用户需求扩展。

十三、文件大小与"科研数据规模"

App 24 的 6 文件大小（420KB ~ 15.6MB）——"科研数据规模"分级：

文件大小类型例子
< 1MB文字/小数据评估结果 420KB
1-10MB普通文件论文初稿 2.4MB / 报告 3.1MB
10-100MB大数据实验数据集 15.6MB
100MB-1GB大数据集图像数据集/视频
> 1GB超大数据基因测序/卫星图像

"科研数据"从 KB 到 TB 跨越 9 个数量级——文件管理系统的扩展性：

  • 小文件（< 1MB）：本地存储即可
  • 中文件（< 100MB）：云存储（OSS/S3）
  • 大文件（< 1TB）：HDFS/对象存储
  • 超大文件（> 1TB）：分布式存储

"科研数据规模"是文件管理系统的核心挑战——App 24 的 6 文件（< 20MB）只是最简场景——真实科研项目应支持 GB+ 文件的"分片上传/断点续传/秒传"。

"大文件上传"的 3 个工程问题：

  1. 超时——上传 1GB 文件需要断点续传
  2. 进度——用户需要看到上传进度条
  3. 重试——网络中断需要自动重试

App 24 的"点击上传"是 demo 简化——真实项目应集成分片上传 SDK + 进度条 UI + 重试机制。

十四、总结

App 24 文件管理页解析完毕。4 模块（Header/Chip/UploadCard/FileList）+ 6 文件 + 4 类型分类 + 虚线边框上传卡是核心组件。"虚线边框整卡可点"是工具型 App 的上传设计标准。"论文+数据集+报告+代码"4 类文件是科研文件的标准分类。"版本号命名 v1/v2/v3"是科研文件的核心元数据。"项目 → 任务 → 文件"三层数据流是科研管理的完整层级。"虚线 = 待填充"是上传卡视觉约定。**"科研 vs 办公"分类哲学、"Git LFS 大文件版本"、"大文件上传的 3 工程问题"**是文件管理的进阶设计。

配图

# 鸿蒙 # ArkUI # 移动开发
Logo
人工智能6S服务平台

作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。

更多推荐

cover

鸿蒙原生应用 ArkTS 表单工程：论文笔记页的 TextArea 录入与笔记列表

avatar 人工智能6S服务平台
cover

鸿蒙原生应用 HarmonyOS ArkTS：科研首页的紧凑布局与项目进度卡

avatar 人工智能6S服务平台
cover

鸿蒙原生应用 ArkUI 声明式：实验室首页的 2 列 Grid 与三状态色

avatar 人工智能6S服务平台