企业官网建设流程全解析

鸿蒙原生应用 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 标题 = 用户当前所在的功能"。

三、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 类型：

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"的最佳轻量上传设计——"虚线 = 待填充"+ 整卡可点 = 简化且功能完整。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

十一、"版本管理"与 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 的"虚线边框整卡可点"是最简上传——对比其他上传设计：

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

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

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

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

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

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

"科研数据"从 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 工程问题"**是文件管理的进阶设计。