在PHP项目中，即使前端控制器逻辑用于主应用程序，也可以有许多独立脚本，ajax片段等。
是否有标准化的方法 - PHPDoc或其他 - 在脚本的第一个注释块中定义脚本将接受/要求的GET和/或POST参数以及它们的类型？
我通常只是添加@param来帮助自己，好像文件是一个函数，并且@return解释了脚本的作用和返回的内容，但也许我有更专业的方法不知道。
答案 0 :(得分：2)
佩卡，
我会考虑使用WADL来记录与API的交互。它没有直接回答你的问题 - 因为它不是从源代码文档，它的XML生成的，而是单独维护的。
它确实直接回答了这个问题：
GET和/或POST参数是什么 脚本将接受/要求和 他们是哪种类型
您可以将样本有效负载与URI参数，接受的内容类型，错误代码/响应/有效负载一起放在文档中。我发现它非常有价值，而且使用WADL，有人可以根据您的API编写客户端代码。
更多信息：http://research.sun.com/techrep/2006/abstract-153.html 并且：http://en.wikipedia.org/wiki/Web_Application_Description_Language
答案 1 :(得分：2)
phpDocumentor不会喜欢文件级 docblock中的 @param 和 @return 标签......
如果您选择单独的文件来记录它们，根据 Mr-sk 的回答，您可以使用 @link 指向那里，但它赢了“在文件的文档页面中立即可见...它只是一个超链接，您必须单击才能查看信息。如果您希望在脚本文件的文档页面上显示该文件的任何内容，则可以使用内联 {@ example} 标记指向它，或者甚至只是指向其中的某些行，例如 {@ example / path / to / file 3 5} 仅显示第3行到第5行。
在这种情况下，我可能会选择在文件级docblock的长描述中解释一些事情，因为实际上并没有直接的方法将参数标记到phpDocumentor将它们识别为代码元素的位置。如果我在描述中使用的任何参数确实是代码元素，它们源自代码中的其他位置，我会使用内联 {@ link} 标记来指向该代码元素。
例如，假设在另一个代码文件中定义了一些常量，并且在解析其他文件时生成这些元素自己的文档。如果我在一个脚本专用文件（如你的）的文件级docblock中编写的长描述将这些常量作为参数进行讨论，那么我的句子可能是：
If $POST['foo'] is set, its value should always be either {@link BAR_CONST} or {@link BAZ_CONST}.
参考文献：
答案 2 :(得分：1)
我会使用@uses或@see
目前我正在使用@uses因为它读得更好而且更有意义
参考：https://phpdoc.org/docs/latest/references/phpdoc/tags/uses.html