- 博客(170)
- 收藏
- 关注
RSS订阅原创 自定义中间件：Node-style 与 Wrap-style 钩子全解析
本文针对LangChain内置中间件难以满足业务自定义需求的问题，介绍hook函数机制。讲解Node-style与Wrap-style共六个钩子及装饰器/类两种实现，剖析多中间件执行顺序，并演示审计日志与动态提示词两个生产级中间件的写法，助你从中间件使用者进阶为作者。
2026-09-01 14:28:46
305
原创 让 Agent 会规划、会干活：TodoList、子 Agent 与执行扩展中间件
Agent 在长任务中会因上下文稀释而“忘目标”，或因报错应激而跳步。本文讲解 TodoListMiddleware 的规划机制：通过 write_todos 工具将计划写入全局 state，每轮注入提醒，强制模型回看清单。以“自动测试并修复 my_add.py”为实战，展示其防遗忘、防跳步的效果，并简介 LLMToolSelectorMiddleware 及四个执行能力扩展中间件，帮助构建会列计划、跑测试、修 Bug 的代码修复 Agent。
2026-09-01 14:26:03
428
原创 Agent容错手册-模型降级-自动重试与工具模拟
LangChain 1.x的四个内置中间件：ModelFallbackMiddleware实现主模型故障时自动降级；ToolRetryMiddleware用指数退避重试工具调用；ModelRetryMiddleware对模型调用重试；LLMToolEmulator用LLM模拟工具执行，支撑零成本测试。助你构建“重试→降级→人工兜底”的分层容错体系。
2026-08-31 17:26:30
348
原创 给 Agent 装上刹车：人工审批、PII 脱敏与调用限额
本文解决什么，如何用三个（准确说是四个）内置中间件为 Agent 建立生产安全边界：危险工具调用前中断等人审批、对话中的 PII 在发给模型服务商前被处理、模型与工具的调用次数被硬性封顶。本文不展开什么，不展开自定义中间件的编写，也不展开 LangGraph 底层 interrupt 机制的原理剖析；本文聚焦"怎么配、怎么跑、输出怎么读"。读完能完成什么，你可以独立实现"调用前中断 + Command 恢复"的人工审批流程，能根据业务场景为五类 PII 选择合适的脱敏策略并编写自定义检测器
2026-08-31 17:09:50
309
原创 上下文压缩双刃剑-Summarization与ContextEditing中间件实战
本文解决什么：SummarizationMiddleware 六个核心参数（model/trigger/keep/token_counter/summary_prompt/trim_token_to_summarize）的语义与坑位，两个完整可运行示例的输出解读，ContextEditingMiddleware 清理工具痕迹的思路与实测对比，以及"摘要/裁剪/清理"三者的选型判断。
2026-08-30 17:29:48
296
原创 Agent的中枢神经-LangChain中间件入门与全景图
中间件（Middleware）——这也是 1.x 版本最具分量的工程化升级。它把 Agent 执行流程切出一个个标准化的"关键节点"，让你把横切逻辑像插件一样挂上去，主流程一行不改。
2026-08-30 17:27:52
535
原创 LangChain Agent 流式执行，进度、Token、工具调用与调试
Agent 的体验问题，常常不是最终答案不好，而是用户不知道它现在进行到哪一步。一次搜索、一次数据库查询或一次多工具规划可能需要几秒甚至更久。如果前端只等最后一个字符串，用户看到的就是一段漫长的空白。开发者也一样，只有最终答案，没有中间事件，就很难知道是模型慢、工具慢，还是 Agent 在重复调用。LangChain 的流式接口可以把 Agent 的运行过程拆成进度、消息、Token、任务和调试事件。不同 `stream_mode` 面向不同消费者，不能把它们当成同一种输出格式。
2026-08-29 16:38:01
442
原创 Agent 的结构化输出，ProviderStrategy、ToolStrategy 与错误重试
单次模型调用的结构化输出，和 Agent 的结构化输出，不是同一件事。前者通常是「给模型一段文本，请模型返回一个固定对象」。后者还要允许 Agent 在过程中调用天气、搜索、数据库等真实工具，等工具循环结束后，再把最终结果整理成一个程序可以消费的结构。如果把这两个层次混在一起，常见结果是，模型一开始就被强行限制成结构化对象，工具调用无法正常进行，或者开发者拿到了中间的伪工具消息，却误以为那是真实业务工具执行结果。
2026-08-29 16:07:55
340
原创 LangChain Agent 入门，create_agent 与 ReAct 工具循环
普通模型调用是一问一答，Agent 则会在一次任务里反复调用模型和工具。用户问「帮我比较北京和上海的天气，再给出出行建议」，模型可能先调用两个天气工具，拿到结果后再次调用模型，最后才生成建议。中间发生了几步，不是因为模型突然变成了一个完整的应用，而是 Agent 运行时替它维护了消息、工具结果和停止条件。Agent 最容易被神化，也最容易被低估。它不是一个更聪明的模型，而是模型、工具、提示词、状态和执行循环组成的系统。理解这层外壳，才知道什么时候该用 Agent，什么时候普通链或确定性工作流更稳。
2026-08-25 13:01:19
310
原创 LangChain中with_structured_output 的验证、解析与 Provider 兼容性
本文深入探讨了使用Schema进行结构化输出时开发者可能遇到的实际问题。文章指出，单纯定义Schema只是第一步，在实际部署时会面临模型供应商支持、JSON模式差异、解析失败处理等挑战。作者通过ContactInfo案例，详细分析了三种结构化输出方法（json_schema、function_calling、json_mode）的边界和风险，强调include_raw=True对于调试的重要性，并提供了完整的可运行脚本示例。文章特别区分了Schema约束、模型输出和应用校验三个环节，帮助开发者。
2026-08-25 12:59:37
303
原创 Pydantic、TypedDict、JSON Schema 与 dataclass，结构化输出怎么选
结构化输出真正让人困惑的地方，往往不是 `with_structured_output()` 怎么调用，而是 Schema 到底应该选哪一种。同一个电影信息抽取任务，可以用 Pydantic、TypedDict、JSON Schema 或 dataclass 描述。它们都能让模型看到字段名和类型，但运行时校验能力、跨语言能力、开发成本和返回值并不一样。把它们混成「都差不多」的四种写法，后面迟早会遇到脏数据。这篇文章不追求把四种 Schema 讲成 API 字典，而是从读者真正要做的决策开始，比较它们
2026-08-24 17:22:58
344
原创 让模型按契约返回数据，LangChain 结构化输出实战
把模型回答交给程序继续处理时，最容易踩的坑是把一段看起来像 JSON 的文本当成真正的结构化数据。模型可能在 JSON 前后加一段解释，也可能把数字写成带单位的字符串，把缺失字段写成「未知」，甚至在同一个字段里混用多个格式。人工阅读时，这些答案似乎都能理解，程序却会在 `json.loads`、数据库写入或条件分支处突然失败。结构化输出解决的不是让模型变得更聪明，而是给输出增加一份可验证的契约。你先定义字段、类型、枚举和嵌套关系，再让 LangChain 把契约转换为模型供应商支持的结构化调用方式，
2026-08-24 17:19:07
244
原创 工具描述决定调用质量，LangChain 工具 Schema 与参数校验
很多时候不是模型突然变笨了，而是工具描述没有把业务边界说清楚。两个工具都叫「查询」，参数一个写 value，另一个写 value2，docstring 只有一句「完成查询」，模型当然很难稳定判断。更麻烦的是，模型即使选对了工具，也可能传入空字符串、错误单位、超出范围的数字，最后把异常推迟到真正访问数据库或第三方 API 的那一刻。Tool Calling 的质量，先由工具 Schema 决定，再由运行时校验和业务规则共同兜底。本文不讨论 Agent 如何编排多个步骤，而是专门解决一个更基础、也更
2026-08-23 17:40:24
302
原创 从函数到工具，LangChain Tools 与 Tool Calling 完整入门
模型只是在对话中生成了一条结构化的「调用请求」，真正执行函数、访问网络、读取数据库的人，仍然是你的应用程序。LangChain Tools 的价值，就是把普通 Python 函数包装成模型能够理解的工具契约，再把模型的调用请求接回运行时，形成一条可观察、可控制的执行链路。
2026-08-23 17:37:37
600
原创 提示词也要工程化, partial、MessagesPlaceholder 与模板库
本文介绍了如何工程化治理LangChain中的Prompt模板，避免版本混乱问题。主要内容包括： 初始示例展示完整Prompt模板实现，包含环境配置和模型调用 区分三类输入数据：固定配置、会话状态和本次输入 使用partial()预填固定变量，支持函数动态生成值 使用MessagesPlaceholder正确处理多轮对话历史 模板组合的最佳实践：按职责组合而非过度拆分 建立模块化模板库的组织方式 通过版本控制管理Prompt的生命周期 文章强调Prompt进入业务后需要像代码一样管理，提供具体技术方案实现P
2026-08-20 18:02:33
353
原创 告别字符串拼接, ChatPromptTemplate 完整入门
文章探讨了在构建LLM程序时，Prompt字符串拼接的局限性问题。随着系统复杂度增加，直接拼接字符串会导致角色边界模糊、变量缺失、历史消息处理困难等问题。作者推荐使用ChatPromptTemplate作为结构化解决方案，它通过消息列表表达角色和变量，能直接与聊天模型集成。文章详细介绍了from_messages()创建模板、三种格式化方法(invoke/format_messages/format)的区别、模板与模型的管道组合使用方式，以及模板如何帮助发现变量错误。
2026-08-20 18:01:33
295
原创 从文本到多模态-读懂content与content_blocks
本文介绍了LangChain中content_blocks的标准化设计及其在多模态AI交互中的应用。主要内容包括： 问题背景：早期纯文本交互简单直接，但随着多模态输入(图片/PDF/音频等)和复杂输出(工具调用/引用等)的出现，不同AI供应商的格式差异导致代码维护困难。 解决方案：content_blocks将不同供应商的内容转换为统一的可遍历结构，支持文本、图像、工具调用等标准类型，但需注意统一的是表示方式而非模型能力。 实践示例：演示了如何通过OpenAI接口发送图片URL或Base64编码图片。
2026-08-18 18:06:18
209
原创 对话历史不是记忆-多轮聊天的上下文治理
本文探讨了聊天机器人开发中的上下文治理问题。以一个在线聊天机器人为例，指出随着对话轮次增加，简单粗暴地删除历史消息会导致模型遗忘关键信息甚至混淆对话内容。文章强调模型本身是无状态的，应用需要负责管理会话状态，包括消息归属、存储策略、内容裁剪和敏感信息处理等关键问题。 通过Python代码示例，展示了如何实现一个最基本的会话管理系统，包括创建独立会话历史、保存完整消息记录等核心功能。同时指出会话隔离和身份验证的重要性，以及无限增长历史消息带来的成本和性能问题。 文章重点讨论了两种历史消息裁剪策略。
2026-08-18 18:04:51
311
原创 大模型为什么会失忆, 彻底理解 LangChain Message
本文介绍了聊天模型中的消息（Message）概念及其在LangChain中的应用。核心内容包括： 消息是聊天程序的基础数据结构，包含角色、内容和元数据三层信息，而不仅是界面上的聊天气泡。 四种主要消息类型： SystemMessage：设定助手行为和边界 HumanMessage：用户输入 AIMessage：模型回复和工具调用 ToolMessage：工具执行结果 多轮对话的实现原理：通过维护包含历史消息的上下文列表。 消息支持字典和对象两种格式，前者适合接口传输，后者适合内部处理。
2026-08-17 16:44:07
310
原创 08-别再只会用print调试LLM---LangSmith追踪实战
本文介绍了LangSmith在LLM应用调试中的核心价值，通过追踪调用链解决"黑箱"问题。主要内容包括： 问题背景：传统日志难以记录LLM多层调用过程，无法定位问题根源。 核心概念： Trace记录完整请求 Run记录每个步骤 Project组织Trace集合 配置指南： 环境变量设置 Python代码示例 元数据标记规范 调试方法： 检查输入输出一致性 分析Prompt实际内容 追踪工具调用流程 监控延迟和Token消耗 生产实践： Project命名规范 tags分类管理 metadata存储上下文
2026-08-17 16:36:49
233
原创 从能调用到能服务, LangChain 的异步、并发与可靠性
本文探讨如何将模型调用（如 model.invoke()）从命令行工具升级为稳定可靠的服务端实现。文章指出异步编程（ainvoke、astream、abatch）只是基础，还需系统性处理五个核心问题：1）同步/异步/并发的本质区别；2）流式响应必须主动消费；3）并发需要动态限流闸门；4）超时、重试、取消的不同处理逻辑；5）有副作用操作必须实现幂等性。最后给出服务端处理器设计框架和上线检查清单，强调可观测性应内置而非事后补丁，并提供了LangChain和Python asyncio的具体实现示例。
2026-08-16 19:54:43
198
原创 在LangChain中invoke、stream、batch 怎么选, 把模型调用讲清楚
本文探讨了LangChain中invoke(), stream(), batch()等方法的区别与应用场景。这些方法不是模型能力的差异，而是结果交付方式的不同选择，直接影响用户体验和系统设计。文章通过客服问答示例，分析了三种核心方法的适用场景：invoke()适用于需要完整结果的单次请求，stream()适合实时展示的流式响应，batch()用于处理独立任务批处理。同时指出了常见误区，如对话失忆、JSON解析失败和并发限制等问题，并强调了消息状态管理和输出契约设计的重要性。最后提出了四个选择方法的关键问题
2026-08-16 19:47:17
308
原创 temperature、max_tokens 和 config, 模型参数应该放在哪里
本文探讨了在AI模型调用中参数管理的常见误区和优化方法。核心观点包括： 参数应分层管理： 连接参数（API密钥、超时等） 生成参数（温度值、最大token数等） 运行时治理参数（调用追踪、并发控制等） 温度值调优实验表明： 低温度适合结构化任务 高温度适合创意任务 温度不影响事实准确性 关键实践建议： 区分初始化默认值和运行时配置 对结构化输出使用Schema校验 必须显式设置超时、重试等关键参数 通过对照实验而非直觉来调参 生产环境需要： 严格参数边界控制 结构化错误处理 完善的监控指标 文章提供了参数分
2026-08-12 14:36:00
334
原创 一套代码接入多家模型, 先弄清模型接入的五个概念
本文介绍了模型接入中的常见问题与解决方案。重点拆解了集成包、服务商、Endpoint、模型ID和凭证五个关键概念，帮助开发者准确定位故障。文章建议从环境变量管理密钥开始，提供了可诊断的最小调用示例，并对比专用模型类与统一入口的适用场景。同时强调兼容接口不等于能力兼容，需建立能力矩阵进行验证。最后给出了按症状快速排错的流程，以及切换模型的合理依据。适合准备接入首个模型服务的Python开发者参考。
2026-08-12 14:35:04
292
原创 LangChain、LangGraph、Deep Agents 如何选
本文探讨了构建采购助手时三种技术方案的选型问题：LangChain、LangGraph和Deep Agents。文章指出这三种方案适用于不同层次的问题，并给出了具体建议：简单任务优先使用LangChain（模型+工具+提示词组合）；需要复杂状态管理和审批流程时使用LangGraph；涉及任务拆分和文件协作的深度任务才考虑Deep Agents。文章强调不应过度设计，并提供了决策流程图和六个关键选型问题，包括状态管理、规则边界和调试能力等。最后指出清晰的系统边界比技术组合更重要，建议先明确业务流程再选择最简实
2026-08-08 14:46:18
197
原创 别急着上Agent-LangChain解决什么问题
本文探讨了构建AI客服助手时的技术选型策略，提出应根据需求复杂度分层选择解决方案。文章将用户问题分为四类：文本生成任务（Prompt）、结构化信息提取（Schema校验）、知识检索（RAG）和系统操作（工具调用），并强调不是所有场景都需要Agent。作者建议通过流程图决策模型选择，指出每增加一层复杂度都会带来测试和维护成本。最后提出五个生产环境检查点：结构化输出、知识依据、工具权限、副作用控制和调用追踪。核心观点是应根据实际需求选择最小可行技术方案，而非盲目使用复杂框架。
2026-08-08 14:44:27
180
原创 uni-app 部署发布策略，开发是一套代码，发布不是一条路
uni-app 虽然支持一套代码多端发布，但各平台上线流程差异显著。H5 发布需关注资源路径、路由回退和缓存策略；微信小程序要注意合法域名、权限申请和审核周期；App 发布需处理证书、版本号和商店规则。关键要点： 生产环境必须隔离配置，避免测试接口误用 H5 子路径部署要同步调整基础路径 小程序审核需预留时间，紧急修复不灵活 App 版本号管理要同时维护展示版本和构建版本 发布后要建立监控和回滚机制 平台差异代码建议集中封装而非散落各处 发布不是终点，需持续观察核心
2026-08-02 13:39:24
476
原创 uni-app 测试调试与质量保证，页面能跑，不等于项目稳定
新手开发 uni-app 项目常见的误区是仅测试"成功路径"就认为项目没问题。文章指出真实用户会遇到各种异常情况，如网络问题、重复操作、异常输入等。作者提出了系统化的调试方法：1)明确复现步骤；2)检查控制台错误；3)查看网络请求；4)核对接口响应字段；5)确认页面状态切换；6)进行多平台真机测试。特别强调不要仅测试"正常用户正常操作"，要覆盖loading/empty/error状态、表单验证、网络异常等场景。建议从纯函数开始编写可测试代码，并为关键流程添加调试开关。调试的本质是找出"现实数据"
2026-07-31 17:58:35
435
原创 uni-app 安全防护与数据保护，前端不能当保安，但也别主动开门
文章摘要 本文针对前端初学者项目中的安全问题，提出5条核心防护原则： 绝不在前端代码中存储密码、支付密钥等敏感信息 Token存储要短期有效且能统一清理，401时强制退出 前端校验仅用于体验优化，安全校验必须依赖后端 日志和错误上报需脱敏处理敏感数据 权限控制、文件上传等功能需谨慎实现 文章通过登录发布流程示意图，明确前后端安全职责边界：后端负责身份认证和权限控制，前端需确保不泄露敏感数据。具体给出token存储方案、请求封装中的401统一处理、表单校验的体验优化等实践方案，强调开发中容易忽视的日志脱敏问题
2026-07-31 17:56:54
225
原创 uni-app 性能优化入门，先从一个变慢的首页查起
本文摘要：性能优化应从实际问题入手，避免玄学。针对移动端首页优化，推荐优先检查图片（使用缩略图+懒加载）、接口请求（避免重复请求+合理缓存）、列表渲染（分页加载+防抖锁）和首包体积（合理分包）。通过定位具体瓶颈而非盲目优化，可显著提升页面性能。文章提供了代码示例和优化优先级流程图，并提醒常见误区如不定位就优化、列表图使用原图等。最后建议通过实践练习分页加载和分包配置来巩固知识。
2026-07-30 16:01:56
237
原创 uni_modules 入门，插件不是复制进项目就完事---插件和uni_modules
本文探讨了 uni-app 项目中 uni_modules 的正确使用方式。uni_modules 不仅是组件目录，更是 uni-app 的包管理方案，包含组件、SDK、页面模板等多种资源。文章建议：1)通用底层能力可用插件，如图标、日期选择器等；2)业务相关组件应自主开发；3)引入插件前需评估维护状态、兼容性、依赖关系等8个关键指标。同时提醒开发者注意插件更新、卸载时的样式和配置清理问题，避免将 uni_modules 简单当作组件目录使用，强调业务组件自主开发的重要性。
2026-07-30 16:00:36
388
原创 uni-app 多端适配，真正难的不是写一套代码--小程序特性与多端适配
uni-app多端适配的关键在于"求同存异"： 统一通用业务逻辑，集中处理平台差异（如分享功能封装到单独文件） 善用条件编译（JS用//、模板用<!-- -->、CSS用/* */） static目录支持平台专属资源隔离 样式适配需考虑安全区和状态栏 重要功能要有降级方案 避免在业务代码中散落平台判断 核心原则不是追求完全一致，而是通过架构设计让90%的代码通用，10%的平台差异可控。
2026-07-26 14:02:05
492
原创 uni-app 上线前 30 分钟检查表，别只看页面能不能点--上线前检查清单
项目能跑，不等于能上线。上线前最容易翻车的，往往不是某个复杂功能。是接口还连着测试环境。是 appid 填错。是小程序合法域名没配。是错误态没测。是图片太大，首页半天打不开。这篇不讲大道理，只给一份能直接照着过的检查表。
2026-07-26 14:00:17
293
原创 uni-app 本地存储，不要把 storage 当成垃圾桶---本地存储与缓存策略
Storage 滥用是常见问题，典型案例如退出登录时误清所有缓存（包括草稿、主题等）。正确使用 storage 需注意： 数据分类：临时状态放内存，用户偏好/草稿可存 storage，敏感信息谨慎处理 清理策略：退出登录时按 key 清除登录相关数据，而非无脑 clearStorage 缓存管理：添加命名空间和过期时间，采用"先读缓存再刷新"策略 平台差异：H5/小程序/App端容量限制不同，避免存储大文件或敏感数据 关键点：Storage 解决的是"下次打开还要用"的需求，而非替代全局变量。
2026-07-23 18:00:08
159
原创 uni.request 不只是发请求，真正麻烦的是页面状态---网络请求与页面状态设计
本文探讨了如何处理前端请求的生命周期问题，特别是搜索场景中旧请求可能覆盖新结果的常见挑战。文章首先展示了uni.request的基础用法，随后通过封装统一的请求工具类（utils/request.js）集中管理域名、状态码和登录失效逻辑。接着提出页面状态的规范化设计（加载中/成功/空/错误等），并给出商品列表页的完整实现示例。针对搜索联想场景，提出两种解决方案：1）通过RequestTask.abort()强制中断旧请求；2）通过请求序号校验避免旧数据覆盖。最后强调complete回调适合做清理工作，并提醒
2026-07-23 17:58:52
305
原创 组件通信与Pinia状态管理--- 三个计数器背后，讲透组件通信和状态归属
本文讨论了Vue状态管理的选择策略，强调不是所有状态都需要全局管理。文章通过计数器案例，介绍了四种状态管理方式： 组件内部状态：适合纯局部状态 props/emit：适合父子组件通信 provide/inject：适合跨层级组件树共享 Pinia：仅当状态需要跨页面/模块共享时才使用 关键结论：状态应优先保持在最接近使用它的组件中，只有真正需要全局共享的数据才放入Pinia。过早使用状态管理会导致代码混乱，建议根据实际场景选择合适的方式，避免将Pinia当作"全局垃圾桶"。 文章通过三个计数器的案例
2026-07-22 16:48:58
234
原创 uni-app 路由导航，用一个商品列表讲清楚页面栈--路由导航与页面传参
uni-app路由导航的核心在于理解页面栈机制。文章通过商品列表到详情页的跳转流程，讲解了四种主要路由API的使用场景： navigateTo - 保留当前页跳转（如列表→详情） redirectTo - 关闭当前页跳转（不需要返回时） reLaunch - 重置整个页面栈（如退出登录） switchTab - 专用于tabBar页面跳转 关键实践建议： URL只传简单参数（如id），详情数据应单独请求 登录后跳首页应避免用户返回登录页 eventChannel适合一次性通信，不适合全局状态管理
2026-07-22 16:47:29
342
原创 v-if、v-show、v-for，不要把列表页写成一堆临时判断-条件渲染与列表渲染
本文总结了列表页开发中的状态管理与条件渲染技巧。首先强调列表页应设计完整状态流转（加载、成功、空态、错误），推荐使用单一status变量管理而非分散的布尔值。关键点包括： 状态设计应优先于代码实现，通过状态图明确各状态间转换关系 v-if适用于互斥状态切换（如加载/成功/错误状态） v-show适合频繁显示隐藏的场景（如筛选面板） v-for渲染列表必须使用稳定业务ID作为key，避免使用数组索引 提供完整商品列表示例，包含状态切换、错误处理和列表渲染 文中通过商品列表示例，演示了如何用status变量统一
2026-07-19 14:38:55
279
原创 uni-app 数据绑定和事件处理，用一个筛选表单讲清楚
页面真正变复杂，往往不是因为元素多，而是因为用户开始操作了。输入关键词。选择分类。调整价格。点搜索。页面要跟着这些操作变化。数据变了，视图要更新；用户点了按钮，方法要执行；某个字段变了，可能还要触发请求。这一篇不用零散例子讲 `ref`、`v-model`、`computed`、`watch`。我们写一个商品筛选表单，把它们串起来。
2026-07-19 14:37:31
469
原创 uni-app 样式和布局，不要一上来就把尺寸写死--样式与布局系统
这篇文章介绍了移动端页面布局的三个核心问题及解决方案：1. 使用rpx和百分比进行响应式尺寸适配；2. 采用Flex布局实现元素排列；3. 为底部固定按钮考虑安全区。文章通过一个商品应用首页布局示例，详细讲解了如何使用rpx确保元素比例、Flex布局实现宫格和商品列表、以及结合safe-area-inset处理底部安全区域。关键点包括：优先使用rpx而非px、理解Flex主轴方向、为图片设置稳定尺寸、给底部按钮添加安全区padding等。这些技巧能帮助开发者避免常见的移动端布局问题。
2026-07-17 15:18:26
300
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人