用途：当 Shiny 应用交互卡顿、加载慢、内存高、并发用户下服务器资源耗尽，或准备面向多用户生产部署时，用本技能做性能画像、诊断与优化。
主要能力：
- 画像定位瓶颈。用 profvis::profvis({ shiny::runApp("path/to/app", display.mode = "normal") }) 或包裹具体运算分析耗时；开启 options(shiny.reactlog = TRUE) 后运行应用，在浏览器按 Ctrl+F3 查看响应式依赖图，找出数据加载、响应式重算、渲染或外部调用等前 2-3 个瓶颈。
- 优化响应式图。拆分数据加载与过滤，把昂贵部分放入带 bindCache() 的 reactive；用 isolate() 避免无关输入触发重算；对搜索框用 debounce(500)、滑块用 throttle(250) 控制高频输入。
- 缓存。输出用 bindCache(input$category, input$date_range) 以输入值为键；函数用 memoise::memoise(..., cache = cachem::cache_disk("cache/", max_age = 3600))；在 global.R 或 server 外预计算全局数据与模型。
- 异步。Shiny >= 1.8.1 可用 ExtendedTask$new(...) 配合 bind_task_button()；旧版用 promises + future，先 plan(multisession, workers = 4) 再 future_promise({...})。注意 future 在独立 R 进程中运行，变量需显式传入。
- 渲染优化。大表用 DT::datatable(server = TRUE)，交互图用 plotly，隐藏元素用 req() 条件渲染。
- 验证。用 system.time() 配合 testServer 做前后对比；用 shinyloadtest::record_session()、shinycannon()、shinyloadtest_report() 做负载测试。
限制与注意：不要过早优化，先画像；缓存键遗漏会导致数据陈旧；缓存过度占用内存；响应式图过于复杂时应重构为模块而非只加缓存；若优化后无改善，需重新画像迭代。预期并发用户数、服务器资源、是否使用数据库或外部 API 等输入为可选，资料未提供相关默认值。