WordPress开发中硬编码URL场景下为何仍需使用esc_url？

首先先纠正示例代码的笔误：你用到的函数正确写法是get_template_directory_uri()，原代码漏了函数括号、后缀拼写有误。
针对你提到的"URL部分内容硬编码、内容本身干净就不需要转义"的误区，核心原因可以拆成这几点：

• 你认为的"完全可控"并不成立
  你写死的/someText确实是安全的，但拼接在前面的get_template_directory_uri()返回值从来不是硬编码内容：它是WordPress根据站点配置动态生成的，且允许所有插件、主题通过过滤器修改返回值。攻击者根本不需要入侵服务器，只要利用站点上任意一个低危漏洞（比如插件的存储型XSS、未授权的过滤器篡改、SQL注入改站点配置），就能污染这个函数的返回值，往里面插入恶意代码。
• 不转义的真实攻击路径不需要服务器权限
  举个最常见的攻击场景：假设站点装了个存在存储型XSS漏洞的评论插件，攻击者提交一条构造好的恶意评论，触发插件错误地给template_directory_uri挂钩了恶意过滤逻辑，把函数返回值篡改为https://你的域名.com" onmouseover="stealAdminCookie()"/assets。这时候你未转义的代码最终输出到HTML里的内容就是：

  https://你的域名.com" onmouseover="stealAdminCookie()"/assets/someText
  

  这段内容如果是输出在href、src这类HTML属性里，双引号会直接闭合属性标签，后续的恶意JS代码会直接在访问者（包括管理员）的浏览器里执行，直接盗取会话权限、篡改站点内容，整个过程攻击者根本没拿到服务器控制权。
• esc_url是输出层的兜底防御，符合纵深安全逻辑
  你提到的"如果攻击者已经入侵服务器，esc_url就没用"是典型的安全认知偏差：没有任何一个安全函数是用来防已经拿到服务器最高权限的攻击者的。esc_url的作用是在输出的最后一道关口，自动把URL里的尖括号、双引号、特殊控制字符、非法协议全部过滤/转义，不管前面的内容是被插件污染、还是被数据库篡改、还是核心函数返回了不规范的内容，都能保证输出到HTML的URL不会打破标签结构、不会触发XSS。
  哪怕你真的把整个URL100%硬编码写死，esc_url的性能损耗也可以忽略不计（单次执行是微秒级的字符串替换），不会对站点速度造成任何影响。
• 代码可维护性的强制要求
  WordPress官方的主题、插件审核规则里，所有输出到前端的URL必须经过esc_url转义，不管内容是不是硬编码——因为你没法保证后续维护的时候，自己或者其他接手的开发者不会把硬编码的部分改成动态调用的内容，一开始写代码就加上转义，能从流程上避免后续迭代漏掉安全逻辑。

不要相信任何进入输出流程的动态内容，哪怕这个内容的生成函数是WordPress官方提供的。输出层转义是WordPress安全开发最基础的原则，不存在"多此一举"的情况。

内容的提问来源于stack exchange，提问作者vwihw5xgpl