我想从StaticFileMiddleware(提供静态文件的"标准"方式，在Startup.cs中用app.UseStaticFiles((初始化(继承。代码会编译，但当我尝试运行它时，我会得到InvalidOperationException("InvalidOperationException:有多个公共的Invoke'或InvokeAsync'方法可用。"(。
这些是代码的重要部分：
public class MyStaticFileMiddleware : StaticFileMiddleware
{
...
public new async Task Invoke(HttpContext context)
{
...
await base.Invoke(context);
...
}
...
}
背景：我想在不改变文件系统中实际文件名的情况下，为某些静态文件引入有意义的文件名(比如现有文件"123.jpg"的"tree-in-a-meodow.jpg"(。因此，MyStaticFileMiddleware应该检查发言文件名的有效性，如果有效，只需执行StaticFileMiddle ware的现有代码即可为文件提供服务。我欢迎这个程序，这样我就不必重新编程StaticFileMiddleware(SRP/KISS(的重要部分。
我有两个问题：
由于StaticFileMiddleware.Invoke((没有标记为"虚拟"，我认为这个过程并不是真正的目的。但我仍然不明白为什么——纯粹从技术上讲——这个程序不起作用。既然我使用"new"修饰符显式隐藏基类(StaticFileMiddleware(的Invoke((方法，难道不应该只有一个而不是"多个公共的Invoke'或InvokeAsync'方法"吗？
相应地扩展现有中间件的"预期"方式是什么？我应该在代码中简单地使用"new StaticFileMiddleware"吗？在这种情况下，我如何将StaticFileMiddleware注入MyStaticFileMiddle中以从依赖注入中获益？
非常感谢您的帮助！
据我所知，中间件访问您的扩展以在管道中包含其他行为。要实现不同的行为，您应该自己实现它，所以扩展应该隐藏实现细节。关于管道
StaticFileMiddleware本身就是StaticFileContext的包装器，所以也许您需要以与StaticFile中间件源相同的方式制作一个新的包装器