Webman视图文件禁止出现new UserModel()、PDO::query()、$_GET/$_POST直读、header()/exit()、短标签；只允许纯展示逻辑，数据须由Controller预处理并安全传入。
Webman 的视图（app/view/）不是模板渲染的“终点站”，而是职责边界最易失守的一环。直接在 view 里查库、调模型、用 $_GET 或拼 SQL，等于把 MVC 拆成 “M+V+C=全在 View 里”。真要落地分层，得从三处卡死：传入数据来源、输出控制粒度、模板可测试性。
View 文件里禁止出现哪些代码
Webman 的视图文件（如 user/profile.php）必须是纯展示层，任何越界行为都会破坏请求生命周期和单元测试可行性：
-
new UserModel()、$this->model或任何类实例化 —— 视图不该持有或创建业务对象 -
require_once 'config/database.php'或PDO::query()—— 数据访问必须由 Controller 统一调度后传入 -
$_GET['id']、$_POST、$_SESSION等超全局变量直读 —— 所有输入应经 Controller 验证并显式传入 -
header()、exit()、echo json_encode(...)—— 视图只输出 HTML 片段，响应头与格式由 Controller 或中间件决定 - 短标签
='xxx'?>—— 若short_open_tag未开启会直接暴露 PHP 代码，统一用<?php echo $name; ?>
Controller 向 View 传参的正确姿势
Webman 的 view() 函数接受两个参数：view('path.to.template', $data)。关键不在“能不能传数组”，而在“传什么、怎么结构化”：
- 只传已处理完成的数据，比如
['user' => $userDto, 'orders' => $orderList]，而非原始PDOStatement或未fetch()的结果集 - 避免传
['user' => $userArray, 'is_admin' => $userArray['role'] === 'admin']这类计算逻辑 —— 权限判断应在 Model 或 Service 层完成，Controller 只做搬运 - 敏感字段（如密码哈希、token）绝不可出现在传参数组中，哪怕 View 里没用到 —— 数据流起点就该过滤
- 大数组建议封装为 DTO 类（如
UserProfileViewData），比关联数组更易维护、IDE 可提示、类型更明确
如何让 View 支持局部复用与条件隔离
Webman 默认不带模板继承或组件系统，但可通过简单约定实现视图分层复用，避免重复写 <header> 和 <footer>：
立即学习“PHP免费学习笔记（深入）”；
- 用
include引入局部模板（如include view_path('common/_navbar.php')），路径需用view_path()而非硬编码相对路径，确保跨环境一致性 - 所有
include文件也遵守 View 约束：不 new、不查库、不读超全局 —— 它们只是“子视图”，不是新入口 - 条件渲染用
if (isset($user['email'])) { ... }，而非if ($userModel->checkEmailExists($user['email']))—— 判断依据必须是 Controller 已传入的布尔值或状态码 - 避免在 View 中做 i18n 翻译（如
__('Welcome')），除非你已确认翻译函数是纯函数、无副作用、且语言包已由 Controller 预加载并传入
最难守住的其实是“View 不该有 if-else 分支以外的逻辑”，很多人觉得“查个缓存不算业务逻辑”，但只要它绕过了 Controller 的调度链路，就等于在架构上凿了个洞。Webman 的高性能建立在清晰的事件流之上，而视图层一旦混入异步调用、数据库连接或配置加载，整个常驻进程的内存稳定性就会出问题。
